sysmap_64bit: rmap ovflo, lost [427196,427197)
sysmap_64bit: rmap ovflo, lost [425697,425698)
sysmap_64bit: rmap ovflo, lost [427684,427685)
sysmap_64bit: rmap ovflo, lost [427297,427298)
sysmap_64bit: rmap ovflo, lost [425994,425995)
sysmap_64bit: rmap ovflo, lost [425214,425215)
sysmap_64bit: rmap ovflo, lost [425182,425183)
sysmap_64bit: rmap ovflo, lost [426500,426501)
sysmap_64bit: rmap ovflo, lost [426885,426886)
sysmap_64bit: rmap ovflo, lost [428726,428727)
sysmap_64bit: rmap ovflo, lost [428082,428083)
sysmap_64bit: rmap ovflo, lost [428341,428342)
sysmap_64bit: rmap ovflo, lost [428184,428185)
sysmap_64bit: rmap ovflo, lost [428231,428232)
sysmap_64bit: rmap ovflo, lost [426115,426116)
sysmap_64bit: rmap ovflo, lost [425105,425106)
Note: If you are the author of this question and wish to assign points to any of the answers, please login first.For more information on assigning points ,click
here
From this document KBRC00000293 which is referred to in the below listed thread you apparently have an application causing a memory leak. I've found detecting memory leaks are best detected when using glance advisor. Here's the thread:
The sysmap being referred to here is the resource map (rmap) which
is used by the kernel to allocate pages of virtual memory to various
kernel-related processes. An rmap overflow is typically the result
of fragmentation: where kernel virtual memory is being freed in
many small, non-contiguous chunks which cannot be combined into
free areas.
You can choose to:
1. Ignore it: it's basically a small memory leak.
2. Figure-out which application is causing kernel virtual memory to become so fragmented as to cause this problem, and get it to do better garbage collection.
3. Increase the size of the resource map so that less will be lost.
Michael: Thanks--the article provides some insight, although it and the patches it refers to are hp-ux 10.20.
Ivan: wtec.cup.hp.com refuses my connections, so I can't read the material.
Elena: When cutting and pasting, it's polite to credit your source, apparently the document referenced by Michael.
More information: This is a K380 running 11.11 and Oracle Financials 11i. Any pointers to literature on this issue in an hp-ux 11 environment will be appreciated.
I was not trying to hide a source, just trying to give you direct info, so you do not have to follow the link. You may try to assign some negative points to me. :)
Elena: Fair enough--you certainly didn't subtract anything from the conversation.
One more piece of info: the customers on the box periodically start complaining that it's "very slow", although we can't find much paging, i/o bottlenecks, cpu spikes, etc. Rebooting usually clears it up for a while.
Just one more thing to share. It looks like a memory leak problem to me (we had that same situation and did reboot weekly ).
To check for memory leaks, generate regular outputs of the following command and see if the first column for any of the processes is growing over time ( this is somebody's posting in this forum):
Printable version
