1753519 Members
4964 Online
108795 Solutions
New Discussion юеВ

sysmap_64bit: rmap ovflo

 
daffodil
Occasional Advisor

sysmap_64bit: rmap ovflo

sysmap_64bit: rmap ovflo, lost [498017,498018)
sysmap_64bit: rmap ovflo, lost [498014,498016)
sysmap_64bit: rmap ovflo, lost [498004,498005)
sysmap_64bit: rmap ovflo, lost [497999,498001)
sysmap_64bit: rmap ovflo, lost [497989,497990)
sysmap_64bit: rmap ovflo, lost [497982,497983)
sysmap_64bit: rmap ovflo, lost [497978,497981)
sysmap_64bit: rmap ovflo, lost [497974,497977)
sysmap_64bit: rmap ovflo, lost [497971,497973)
sysmap_64bit: rmap ovflo, lost [497966,497970)
sysmap_64bit: rmap ovflo, lost [497964,497965)
sysmap_64bit: rmap ovflo, lost [497962,497963)
sysmap_64bit: rmap ovflo, lost [497958,497961)

Receiving such alerts on HPUX B.11.11 U 9000/800.

____
This info's can help to analyze.. i hope..

# kmtune -q nsysmap64
Parameter Current Dyn Planned Module Version
===============================================================================
nsysmap64 8192 - ((NPROC)>800?2*(NPROC):800)
_______
# swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 10240 3503 6737 34% 0 - 1 /dev/vg00/lvol2
dev 10240 3507 6733 34% 0 - 1 /dev/vg_localQ30/swap1
reserve - 12450 -12450
memory 4662 904 3758 19%
total 25142 20364 4778 81% - 0 -
___________


B3692A GlancePlus C.03.55.00 12:18:39 ******* 9000/800 Current Avg High
-----------------------------------------------------------------------------------------------------------------------------
CPU Util S SU U | 29% 16% 29%
Disk Util F FV | 8% 14% 39%
Mem Util S SU UB B | 99% 99% 99%
Swap Util U UR R | 81% 81% 81%
-----------------------------------------------------------------------------------------------------------------------------
PROCESS LIST Users= 1
User CPU Util Cum Disk Thd
Process Name PID PPID Pri Name ( 800% max) CPU IO Rate RSS Cnt
--------------------------------------------------------------------------------
jlaunch 29042 28642 168 dm1adm 83.7/ 7.3 88143.2 4.3/ 1.7 764.3mb 173
opcmon 21715 21545 152 root 16.1/16.1 0.8 0.0/ 0.0 32kb 1
opcmon 21729 21545 152 root 15.9/15.9 0.8 0.0/ 0.0 32kb 1
opcmon 21736 21545 152 root 15.9/15.9 0.8 0.0/ 0.0 32kb 1
opcmon 21708 21545 152 root 15.7/15.7 0.8 0.0/ 0.0 32kb 1
____________________

Kindly suggest me...to resolve this issue...Thanks in advance...
3 REPLIES 3
Avinash20
Honored Contributor

Re: sysmap_64bit: rmap ovflo

inf1 vmunix: sysmap: rmap ovflo, lost
[317771,317781?

RESOLUTION

The first portion of the message, inf1, is the hostname of the system
that is having the error.

The next part, vmunix, is the process that is logging the error, which is
the kernel.

The actual error is sysmap: rmap ovflo.

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. Since a resource map structure contains an entry for
each contiguous chunk of free virtual memory, the more fragmentation
that exists, the more discreet chunks of memory must be managed,
which may overflow the finite resource map. You can choose to:

1. Ignore it: it's basically a small memory leak, as virtual
addresses fall off the end of the map and cannot be used again.
Since they're virtual addresses, however, and there are no other
resources associated with them, this will not impact your system
unless you're bothered by the warning messages or if a later
allocation fails due to a lack of virtual space. If your system
has paniced, this is not a good option.

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. From HP-UX
10.x to 10.20, the number of map entries is determined by 2*nproc, if nproc
is larger than 800. Otherwise, the number of entries is set to 800. In HP-UX
10.30 and later, the kernel tunable nsysmap allows you to
appropriately size the map. Each proc entry is several hundred bytes in

size, whereas each sysmap entry is just 8. The workaround for the panic

caused by sysmap fragmentation is to increase nproc (to greater than 800) or

nsysmap in order to increase size of sysmap and reduce the chance of
resource map overflow.
"Light travels faster than sound. That's why some people appear bright until you hear them speak."
V. Nyga
Honored Contributor

Re: sysmap_64bit: rmap ovflo

Hi,

have you already tuned your kernel configuration?
The standard configuration sometimes is not enough ...
Here's a guide (for 11.0 - there can be some new ones at your side):
http://docs.hp.com/en/1219/tuningwp.html
Here is one page of the official HP dokument:
http://docs.hp.com/en/B2355-60105/maxssiz.5.html
It's more difficult to navigate inside ...
To increase 'maxssiz' maybe can help you too.

HTH
Volkmar
*** Say 'Thanks' with Kudos ***
V. Nyga
Honored Contributor

Re: sysmap_64bit: rmap ovflo

Hi again,

check also this tool:
http://docs.hp.com/en/diag/ems/emd_kern.htm

HTH
Volkmar
*** Say 'Thanks' with Kudos ***