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