wrong VM numbers reported ...

[Sudhir C]

we are seeing some Virtual memory numbers as reported by top, glance & vmstat (all showing the same number) that is a bit baffling.

the system has 5GB phy.memory and 4GB of disk swap configured. all of the above commands are showing 20GB of VM in use !!!

swapmem_on is set to 1;

am left wondering if i got a buggy system or command set.

#/usr/sbin/swapinfo -mt

Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 417 3679 10% 0 - 1 /dev/vg00/lvol2
reserve - 3679 -3679
memory 3854 1414 2440 37%
total 7950 5510 2440 69% - 0 -

$ egrep -i phy syslog.log
May 26 17:53:46 apolo vmunix: physical page size = 4096 bytes, logical page
size = 4096 bytes
May 26 17:53:46 vmunix: Physical: 5242880 Kbytes, lockable: 3939012 Kb
ytes, available: 4532752 Kbytes
anyone wanna shed some light here ?

[Steven E. Protter]

swapinfo patch for 11.00

http://www2.itrc.hp.com/service/patch/patchDetail.do?patchid=PHCO_22676&context=hpux:700:11:00

http://www2.itrc.hp.com/service/patch/patchDetail.do?patchid=PHKL_22771&context=hpux:800:11:00

For 11.11

None.

Try swapinfo -tam the results might be different.

By looking at your results it might be possible to explain the discrepency.

Lets assume you are running 11.00. Try the patches or a different set of command switches and see if you get better results.

SEP

[Sudhir C]

thanks for the reply Stephen. i should have thrown in a few other details ...

the system is running 11.11;
even when we add up all of our proc sizes, "ps -o vsz", they add upto no more 5GB of total utilization ( we know we have a memory crunch; we are trying to make sense of the numbers being reported).

looked at "ipcs -ma" to find any large shared memory segments and the numbers don't add up. not even close.

[Sudhir C]

and here is the top output and the swapinfo output ...

Load averages: 0.04, 0.14, 0.32
383 processes: 220 sleeping, 163 running
Cpu states:
CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS
0 0.17 2.0% 0.0% 0.0% 98.0% 0.0% 0.0% 0.0% 0.0%
1 0.01 2.0% 0.0% 4.9% 93.1% 0.0% 0.0% 0.0% 0.0%
2 0.00 0.0% 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%
3 0.00 15.7% 0.0% 28.4% 55.9% 0.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- -----
avg 0.04 4.9% 0.0% 8.8% 86.3% 0.0% 0.0% 0.0% 0.0%

Memory: 3025904K (2956728K) real, 21471320K (21005660K) virtual, 1180396K free
Page# 1/192

CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
0 ? 1278 root 154 10 13720K 544K sleep 249:55 6.93 6.92 diagmond
3 ? 1961 root -16 20 11132K 10564K run 58:02 1.59 1.59 midaemon



# swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 1522 2574 37% 0 - 1 /dev/vg00/lvol2
reserve - 2574 -2574
memory 3854 1978 1876 51%
total 7950 6074 1876 76% - 0 -

[Bill Hassell]

swapinfo reports just under 8Gb of virtual memeory. Note that virtual memory is all memory, whether in use or paged out. There is about 1500 megs paged out. Adding up processes using ps doesn't work well because of the very complex memory management features. For instance, for 10 copies of the same program, there is only one text copy (the unchanging instructions), a unique data and stack area, and for IPC programs, shared areas for shared libraries, memory mapped files and shared memory segments--these exist but are difficult to assign to a specific process. And top's numbers are pretty much worthless due to the outdated methods used in the old code. Galnce is much better in presenting memory usage.

Then there's the buffer cache and kernel memory...so rather than look at memory usage, look at paging rates. Use vmstat and ignore pi (page in), but look at po (page out). If the numbers are low (under 2 digits), you don't have any memory pressure. High 2 digit values are warning signs and 3 digits (for long periods) indicate it's time to buy a LOT more RAM or live with slow performance.

Be sure your buffer cache is resonable in size (200-500 megs). If SAM says the dbc max percent is 50, then change it immediately to a max of 200-500 or so.

[Sudhir C]

Bill,
we are still trying to figure out where the 20GB VM usage comes from. as i said even glance and vmstat are reporting 20GB of VM !!! procs are getting deactivated and vmstat is showing no pageouts. but the 'scan rate - "sr" ' reported by VM is in the 20's and 30's showing that it had severe memory shortages !

well as for adding up all of the proc sizes from 'ps', we do realize that it isn't an accurate number, but the point was that the numbers didn't even approach anywhere near 20GB (even with all the shared memory segments that the procs are possibly using)

we are looking for an explanation for the 20GB number being reported ! the HP support personnel haven't been of any help till now.