From: Hari (indhp@yahoo.com)
Date: Mon Jun 17 2002 - 03:11:36 EDT
Hi admins,
Special thanks for the the Answer Given by HAUTECOEUR Bruno .....its excellent .......
Thanks to all
Cheers
HAUTECOEUR Bruno <HAUTECOB@ESSILOR.fr> wrote: Hi Hari,
here is a HP doc explaining this message:
Text1sysmap: 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.
There is a known issue at HP-UX 10.20: there is a sysmap fragmentation
problem caused by the way super pages are created on the HP-UX 10.20
release. As of April 14, 1998, the list of patches (including patch
dependencies) to address this problem is as follows:
[PHKL_14686/PACHRDME/English]
[PHCO_12923/PACHRDME/English]
[PHCO_14628/PACHRDME/English]
[PHNE_14271/PACHRDME/English]
[PHKL_12340/PACHRDME/English]
Please note that this list will change as patches become superseded. The
patches
above only fix the problem on systems that use super pages. To determine if
the
patches should fix the problem, use the adb command to check the kernel
global
cpu_has_var_size_pages. For example:
Command: echo cpu_has_var_size_pages/D | adb /stand/vmunix /dev/kmem
Output: cpu_has_var_size_pages:
cpu_has_var_size_pages: 0 or 1 <---
If this variable is ONE (1), then the system supports super pages, and
the patches are applicable.
If this variable is ZERO (0), then the fragmentation is from other
causes.
It may be that the "high-water mark" for sysmap needs to be determined on
the
system. Do this by increasing nproc or nsysmap to some large value, then
monitor
sysmap fragmentation. Sysmap usage should "settle" to some high-watermark.
If it
doesn't (that is, it continues to rise and you get the ovflo messages) then
either there's a leak somewhere, or large enough number was not chosen in
the
first place. Unfortunately there's no rule of thumb.
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 creating
many small areas of free space.
Installing patch PHKL_16751 and it's dependencies may help. This patch
fixes a fragmentation problem that occurs on PA8000 systems. If the
system has a PA7200 CPU, it is still a very good idea to have
this patch set on your system.
PHCO_16591 fsck_vxfs(1M) cumulative patch
PHKL_16751 SIG_IGN/SIGCLD,LVM,JFS,PCI/SCSI cumulative patch
PHKL_16957 Physical dump devices configuration patch
PHKL_17858 Fix for mount/access of disc sections
PHCO_18563 LVM commands cumulative patch
PHKL_19159 Correct process hangs on ufs inodes
PHKL_19540 VxFS (JFS) mount,fsck cumulative changes
PHNE_19936 cumulative ARPA Transport patch
PHKL_20483 LOFS cumulative patch
Use this unsupported script to monitor sysmap after an rmap overflow:
#!/usr/bin/sh
# a crude tool to monitor sysmap fragmentation
# print warning to stderr if less then WARN percent of
# sysmap entries are free, or no chunk of size MINCHUNK available
# WARN=10 and MINCHUNK=50000 are guesses only, no scientifically
# determined default values
# may be adapted to 9.X (but why?), possibly to read dumps # or other
maps
typeset -i WARN=10
typeset -i MINCHUNK=50000
ADB=/usr/bin/adb
OPT="-k /stand/vmunix /dev/kmem"
get_one_value()
{
echo "$1"|$ADB $(echo $OPT)|awk -F: '/[0-9]/{print $2}'
}
typeset -i SYSMAP=$(get_one_value sysmap/D)
typeset -i SYSMAP_END=$(get_one_value "sysmapNSYSMAP/D")
typeset -i SYSMAP_END1=$(get_one_value "0d$SYSMAP/D")
if [ $SYSMAP_END -ne $SYSMAP_END1 ]; then
echo $0: Unable to determine size of sysmap -
exiting >&2
exit 1
fi
(( MAPSIZE = ( SYSMAP_END - SYSMAP ) / 8 ))
(( MAPLINES = MAPSIZE - 2 ))
(( SYSMAP = SYSMAP + 8 ))
typeset -i FREE=0
(echo "0d$SYSMAP/2D"; yes "" | head -n $MAPLINES)\
| $ADB $(echo $OPT) |
awk ' { if ( ($2 == 0) && ($3 == 0) )
{ FREE = FREE + 1 }
else { FREE = 0 }
if ( $2 > MAX ) { MAX = $2; }
}
END { print FREE, MAX } ' |
read FREE MAX
echo $FREE of $MAPSIZE entries in sysmap are free
echo maximum available chunk size is $MAX
typeset -i PCT=0
(( PCT = ( 100 * FREE ) / MAPSIZE ))
if [ $PCT -lt $WARN -o $MAX -lt $MINCHUNK ]; then
if [ $PCT -lt $WARN ] ; then
echo $0: Warning: less than $WARN percent of sysmap are free
>&2
fi
if [ $MAX -lt $MINCHUNK ]; then
echo $0: Warning: no chunk of size $MINCHUNK in sysmap >&2
fi
exit 1
else
exit 0
fi
feedbackform _____
Rgds,
________________
Bruno HAUTECOEUR
Architecte système Unix
DSI / Architecture Technique - Essilor International
Tel: 33 (0)1 48 98 73 20 / Fax: 33(0)1 49 56 20 56
mail: hautecob@essilor.fr
-----Message d'origine-----
De: Hari [mailto:indhp@yahoo.com]
Date: jeudi 13 juin 2002 12:05
À: hpux-admin@dutchworks.nl
Objet: [HPADM] Error in NIS Server
Hi admin,
Our NIS server ( B132L+ with HP 11i ) is logging the following error message
in its syslog.log since today morning. Can someone tell me what does this
error mean ?
Jun 13 14:10:21 mercury vmunix: sysmap_32bit: rmap ovflo, lost [18632,18634)
Regards
HP
_____
Do You Yahoo!?
Sign-up
for
Video Highlights of 2002 FIFA World Cup
---------------------------------
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup
--
---> Please post QUESTIONS and SUMMARIES only!! <---
To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl
Name: hpux-admin@dutchworks.nl Owner: owner-hpux-admin@dutchworks.nl
Archives: ftp.dutchworks.nl:/pub/digests/hpux-admin (FTP, browse only)
http://www.dutchworks.nl/htbin/hpsysadmin (Web, browse & search)
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 11:02:14 EDT