Syslog and Dmesg errors

[Tommy Brown]

Hi,
Has anyone seen the following message on 11.0 systems?
Sep 5 01:47:42 cindylou vmunix: sysmap_32bit: rmap ovflo, lost [11601l,11603l
This is happening in the early hours, with about 10 to 20 consecutive reports. then goes away for a while.
This is the only system that has this message. It is fairly current in patch level and is basically my internal (10.0) network primary DNS server. The machine is an A180C. A near twin that run external DNS is not having the errors.
Thanks,
Tommy

[Scott_14]

Hello:

Well, I am tring to remember, I had this come up last year, and found out that increases my nproc kernel parameter helped solve the problem.

I wish I could recall, I beleive there may be one more parameter you need to look at, and im sure someone will know.

[Vito Sarducci]

( SR: 8606103778 CR: JAGab70853 )64bit systems with large amount of memory (e.g. 32Gb) and
having large buffer cache (e.g. 8Gb) configured find the
syslog is flooded with the following error message:

vmunix : bufmap : rmap : ovflo, lost [xx..)(xx..]

s700_800 11.04 (VVOS) probe,sysproc,shmem,thread cuml patch resolves this problem. Check out the following url:

http://us-support2.external.hp.com/cki/bin/doc.pl/sid=6a976d021dc9fb07a9/screen=ckiDisplayDocument?docId=200000055184911

Vito

[Vito Sarducci]

Check out this url as well.

http://us-support2.external.hp.com/cki/bin/doc.pl/sid=6a976d021dc9fb07a9/screen=ckiDisplayDocument?docId=200000056273295

HTH,

Vito

[Magdi KAMAL]

Hello Tommy,

You may increase the resource map "nsysmap" value to fix this problem ( by increasing the nproc parameter ).

As said before :
nsysmap = 2 * nproc

Have a look on the following :

http://www.docs.hp.com/cgi-bin/otsearch/getfile?id=/hpux/onlinedocs/os/11i/kcparams/KCparam.Nsysmap.html&searchterms=rmap&queryid=20010905-061040


Magdi

[Tommy Brown]

Thanks, Scott and Vito.
I checked the NPROC and it is set for 1461.. The only non "OS" Process running are XNTP and NAMED. THe last patches installed were the FTP and LP patches for security. The memory on this unit is 128Mb. and the OS is 11.0. The unit ran well for a couple of weeks after the last (LP spooler) patch was installed, so I don't think it is patch related.

[Tommy Brown]

Thanks, Magdi
I cannot find the NSYSMAP parameter to set.
This is a 32bit machine running 11.00 single CPU with 128Mb memory..

[linuxfan · Accepted solution]

Hi Tommy,


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/

In 10.20 there was a patch which addressed this issue.

-Regards
Ramesh