sysmap_64bit: rmap ovflo

[W.C. Epperson]

What does this output from dmesg mean?

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)

[Michael Steele_2 · Accepted solution]

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:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xebf3911284f5d5118ff40090279cd0f9,00.html

[Ivan_42]

Hi,
try to have a look to this URL:
http://wtec.cup.hp.com/~hpux/crash/FirstPassWeb/PA/trap_panic/fragmentation.htm
Maybe it could help you.
Ivan.

[Elena Leontieva]

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.

Installing PHKL_28766 may help.

[W.C. Epperson]

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.

[Elena Leontieva]

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. :)

[W.C. Epperson]

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.

[Elena Leontieva]

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):

UNIX95= ps -e -o "vzs args" | sort

[Elena Leontieva]

Sorry, it should be:
UNIX95= ps -e -o "vsz args" |sort

[Srinivas Obulasetty]

Run Xstm gui and check for memory leakage is really problem or some other problem ,long time back I also got same problem,it helpful for me.