Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

"svmon -G" vs "vmstat" for memory utilization 1

Status
Not open for further replies.

hfaix

MIS
Nov 25, 2003
596
US
Can any one explain to me why I have different memory utilization when comparing "svmon -G" vs "vmstat 5 5"

an svmon -G shows :
total : frames=6291440 ( 24 GB)
inuse : frames=6281316 (23.9 GB)
free : frames=10124
( frames *4*1024 ) to get bytes

however, when I do a "vmstat 5 5" I get something like:
avm = pages=2578477 (9.84 GB)
fre = pages=4484 (0.02 GB)
one page = 4096 bytes

which means the vmstat isn't "reporting" 14 GB of RAM, which the system does have. Does this mean those are inactive?

Maybe this is my misunderstand of avm (active virtual memory pages).

 
AVM is "Active Virtual Memory". This does not equate to the amount of memory available on the system. The number you get from svmon is the correct number.

Jim Hirschauer
 
vmstat summarizes the total "active" virtual memory used by all of the processes in the system, as well as the number of real-memory page frames on the free list. Active virtual memory is defined as the number of virtual-memory working-segment pages that have actually been touched. It is usually equal to the number of paging-space slots that have been assigned. This number can be larger than the number of real page frames in the machine, since some of the active virtual-memory pages may have been written out to paging space.



Mike

"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant."

 
So, if vmstat avm number is significantly smaller than the numbers from SVMON, does that mean the memory isn't "really" being used? The machine isn't paging at all.
 
Seems like you (your boss) wasted a lot of beer money ;-) huh?

Run topas and look at the memory usage, I'll bet you'll see about 50% computational and 50% (sum) of noncomputational and client usage

That's just showing that all your processes together use up about half the memory, the rest is being used for file IO cache.


HTH,

p5wizard
 
computational = 44.0
noncomputational = 56.8

As much as RAM in the new p5 systems costs (I'm looking at 2 more to replace p4 machines), 12 wasted GB's is a lot of beer. Around here DBA's ran the place until I started about 2 years ago. I'm still cleaning up the mess :)

Thanks for your help.
 
Hey, I didn't say all that memory is wasted, a reasonable size database will generate a lot if file IO and if there's memory available, AIX will utilize it for file IO caching purposes.

You can use ioo to tune the max pct of memory that you allow AIX to utilize as file IO and check if that adversely affects your database server's performance. If it doesn't, well then that WAS beer money ;-)


HTH,

p5wizard
 
thanks for the posts p5wiz. I always struggle with Memory of AIX.
 
Or build a ramdisk for a quicker doom server.....

Mike

"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant."

 
VMSTAT's avm field
avm stands for "Active Virtual Memory" and not "Available Memory". The avm value in VMSTAT indicates the average number of 4K virtual memory pages that have been accessed but not necessarily paged out. With the previous policy of late page space allocation, avm was equivalent to "paging space blocks" since the VMM would allocate one paging space disk block for each working page that was accessed. With the current deferred allocation policy, the page space disk blocks are allocated at the time the pages are actually paged out. The avm number will grow as more processes get started and/or existing processes allocate more working storage. Likewise, the avm number will shrink when processes (not threads) terminate or are released by the disclaim ( ) system call. They are not released by the free ( ) system call.

VMSTAT's fre field
fre is the average number of 4K pages that are currently on the free list. When an application terminates, all of its working pages are immediately returned to the free list. Its persistent pages (files), however, remain in RAM and are not added back to the free list until they are stolen by the VMM for use by other programs. Persistent pages are also freed if the corresponding file is deleted.

For these reasons, the fre value may not indicate all the real memory that can be readily available for use by processes. If a page frame is needed, then persistent pages previously referenced by terminated applications are among the first to be handed over to another program.

The minimum number of pages that the Virtual Memory Manager keeps on the free list is determined by the minfree parameter of vmtune. If the number of pages on the free list drops below minfree, the Virtual Memory Manager will steal pages until the free list has been restored to the maxfree value.


Explanation of svmon output
SIZE Total size of memory in 4K pages

INUSE Number of pages in RAM that are in use by a process plus the number of persistent pages that belonged to a terminated process and are still resident in RAM. This value is the total size of memory minus the number of pages on the free list.

FREE Number of pages on free list.

PIN Number of pages pinned in RAM (a pinned page is a page that is always resident in RAM and cannot by paged out)

VIRTUAL Number of pages allocated in the system virtual space (version 4.3.3 or later)

Pgspace:

SIZE Total size of paging space in 4K pages

INUSE Total number of allocated slots. (see "Paging space allocation and Virtual Memory" above)

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top