Syslog.log

[Andrew Brain or Yong Ji]

I keep getting the following message in my syslog.log file, what does it mean?

< Jul 17 14:17:18 wck1001 vmunix: sysmap: rmap ovflo, lost [43583l,43584l)
< Jul 17 14:17:18 wck1001 vmunix: sysmap: rmap ovflo, lost [43573l,43574l)
< Jul 17 14:17:18 wck1001 vmunix: sysmap: rmap ovflo, lost [43568l,43570l)
< Jul 17 14:17:18 wck1001 vmunix: sysmap: rmap ovflo, lost [43417l,43419l)
< Jul 17 14:17:18 wck1001 vmunix: sysmap: rmap ovflo, lost [43387l,43388l)
< Jul 17 14:17:18 wck1001 vmunix: sysmap: rmap ovflo, lost [43164l,43167l)

[RikTytgat]

Seems like a problem that should be taken care of by installing the patch PHKL_21532.

From the patch text:

"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..]"

Hope this helps,
Rik

[Patrick Wessel]

just to give you some background to this message:

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.


If the patch does not help, you have two other choises:

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.

[melvyn burnard]

One other kerenel parameter to be aware of:
nfile can, if too large, also casue this system map fragmentation, and should eb lowered if a high value is currently set.