system administration

[David Almada_1]

hi, everyone
I found the message :
vmunix:sysmap:rmap ovflo , lost .. in syslog.log.
what it means,why it happens?
thanks for your help
david almada

[Alex Glennie · Accepted solution]

take a look at KBRC00000293 for detailed explanation

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 basically chose to ignore it, work out which application is causing it or increase the size of the resource map so that less will be lost see kernal params nsysmap & nproc

[linuxfan]

Hi David,

This is the portion of the Doc KBRC00000293
which describes this problem.

If your nproc value is less than 800 (kmtune -l -q nproc) then nsysmap is configured to be 800 if not nsyspmap is configured to be 2*nproc, so if you want to avoid this messages, you may want to increase the nproc.


/Begin/
sysmap: rmap ovflo error
DocId:
KBRC00000293

Updated:
5/8/00 11:17:30 AM


PROBLEM

What is the meaning of the error 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.


/End/


-Ramesh