sysmap: rmap ovflo, lost [number,number]

sysmap: rmap ovflo, lost [number,number]

Post by Mike Hammern » Wed, 11 Aug 1999 04:00:00



I have followed the threads of previous messages regarding sysmap errors
but I am receiving one that I have not seen discussed in this group.  When
I use dmesg I receive multiple lines like the following.

 # dmesg

Aug 10 10:18
...
 ovflo, lost [26392l,26393l)
sysmap: rmap ovflo, lost [26373l,26374l)
sysmap: rmap ovflo, lost [26354l,26355l)
sysmap: rmap ovflo, lost [26316l,26317l)
sysmap: rmap ovflo, lost [25673l,25674l)
sysmap: rmap ovflo, lost [25617l,25619l)
sysmap: rmap ovflo, lost [25605l,25608l)

I would appreciate receiving an answer as to what causes this but I would
also like an explanation or reference to any document that discusses
various failure possibilities with sysmap and how to trouble shoot them.

Thanks in advance

Hammer

 
 
 

sysmap: rmap ovflo, lost [number,number]

Post by Sven Herbers-Le » Wed, 11 Aug 1999 04:00:00


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
    due better garbage collection.

 3. Increase the size of the resource map so that less will be lost.
    The sysmap rmap defaults to a minimum of 800 entries, but will
    scale up to 2*nproc.  So, increasing the size of nproc will
    increase the size of the rmap.  If it's possible to increase nproc
    without causing other adverse effects, this is probably the best
    solution.

Another possible explanation is:
A high ninode can increase sysmap fragmentation and this is a normal
phenomenon, not a defect.  VxFS dynamically allocates inodes, and as
they are allocated and freed, sysmap usage fluctuates accordingly.
The high fragmentation can come about when ninode is a large number
(although VxFS inodes are dynamically allocated, ninode is used to
calculate the upper bound on the number of inodes), and something like
a backup (or even a find) is performed.  What happens is that as the
VxFS file system is traversed, new inodes are allocated and sysmap
usage increases.  The fragmentation comes about as those inodes are
freed: they may not be freed in a manner which allows the kernel to
coalesce the released space into existing areas of free space, thus
created many small areas of free space.  If possible decreasing ninode
is a solution.

Regards,
Sven


> I have followed the threads of previous messages regarding sysmap errors
> but I am receiving one that I have not seen discussed in this group.  When
> I use dmesg I receive multiple lines like the following.

>  # dmesg

> Aug 10 10:18
> ...
>  ovflo, lost [26392l,26393l)
> sysmap: rmap ovflo, lost [26373l,26374l)
> sysmap: rmap ovflo, lost [26354l,26355l)
> sysmap: rmap ovflo, lost [26316l,26317l)
> sysmap: rmap ovflo, lost [25673l,25674l)
> sysmap: rmap ovflo, lost [25617l,25619l)
> sysmap: rmap ovflo, lost [25605l,25608l)

> I would appreciate receiving an answer as to what causes this but I would
> also like an explanation or reference to any document that discusses
> various failure possibilities with sysmap and how to trouble shoot them.

> Thanks in advance

> Hammer


 
 
 

1. sysmap: rmap ovflo, lost [1992881,1992891]

Hello,

I'm quite new to HP-UX and I have a question for the HP-UX gurus:

When doing the dmesg command I've got a lot of lines like this one:

sysmap: rmap ovflo, lost [1992881,1992891]

I just don't know what that mean, the only thing I can say is that we
have memory problems on this system,
processes requesting large amount of memory fails.
System is HPUX 10.20, 4 cpu, 3GB RAM 6GB swap.

Any help or suggestion will be greatly appreciated.

--
---------------------------------------------------------------------
 Pierre BERGDOLT                        Alcatel TITN Answare
 System Engineer                        Network Applications Division
 Tel: +33 (0)1 69 81 12 79              Customer Care & Billing Department
 Fax: +33 (0)1 69 81 17 39              1, rue Ampre

----------------------------------------------------------------------

2. Sorry: I had to try it!

3. "sysmap: rmap ovflo, lost [61086,61087)"

4. SW2000 Possible BUG

5. "sysmap: rmap ovflo" error

6. Joni Mitchell and the Y2K Problem?

7. vmunix: sysmap: rmap ovflo

8. FS: KAPRO 1

9. What does it mean: 'sysmap: rmap ovflo'

10. Error Msg - vmunix: sysmap: rmap ovflo

11. syslog filling with sysmap: rmap ovflo messages

12. sysmap: rmap ovflo

13. vmstat: is the key metric page-in numbers or page-out numbers?