Izlaz vmstat komande

Na HP Unix-u to izgleda otprilike ovako :

# vmstat 5
Wed Feb 27 00:00:00 MET 2013
procs memory page faults cpu
r b w avm free re at pi po fr de sr in sy cs us sy id
1 0 0 3966196 2782441 34 2 0 0 0 0 0 2325 8334 1762 2 1 97
2 0 0 3959599 2780803 0 0 0 0 0 0 0 2236 2726 785 1 1 98
1 0 0 3953955 2781521 0 0 0 0 0 0 0 2223 2736 787 1 1 98
1 0 0 3950221 2782172 43 0 0 0 0 0 0 2229 4540 787 1 1 98
2 0 0 3963204 2780835 0 0 0 0 0 0 0 2229 2680 769 1 0 99
1 0 0 3957375 2782172 0 0 0 0 0 0 0 2232 3366 772 1 1 98

procs: kernel threads
r : threads placed in run queue (runnable threads) or are already ecexuting (running)
Ako “r” pređe broj procesora na sistemu, možda bi trebalo povećati broj procesora, jer to znači da zadaci upućeni procesoru moraju da čekaju na izvršenje
b : threads placed in virtual memory waiting queue (b=blocked queue,waiting for resource
Ako je “b” veliko, to ukazuje na spore diskove.
“r” treba da je UVEK veće od “b”
avm: The amount of active virtual memory pages (in 4k pages) you are using, not including file pages.
“Over memory commitment would be a situation where AVM would be greater that the installed RAM. It is good to keep AVM at or less than 80%.”
avm*4K treba da je manje od ukupne RAM memorije.
free: The size of your memory free list.
We don’t worry when free is small, as AIX loves using every last drop of memory and does not return it as fast as you might like.
pi : Pages paged in from the paging space. (if there is any it is not a problem)
Page-in se događa ako server ima manjak RAM memorije, bilo kakva ne-nulta vrednost za pi ukazuje na dati manjak
po : Pages paged out to the paging space. (if there is any this could be a pronlem!)
fi : file system reads
fo : file system writes
fr : Pages freed (replaced)
sr : pages scanned (pages should be scanned to see if it could be freed)
If sr is much higher than fr (5 times higher) than it should take your attention.
in: interrupt rate (hardware interrups against the network or san… it is good if it is not high)
sy: system calls (this amount shows how much work is done by the system, if it is a 6 digit number it is doing a lot of work)
cs: context switch (process or thread switch) (the rate is given in switches per second)
It is not uncommon to see the context switch rate be approximately the same as device interrupt rate (in column)
If cs is higher then sy, system is doing more context switching than actual work.
When you are seeing blocked processes or high values on waiting on I/O (wa), it usually signifies either real I/O issues where you are waiting for file accesses or an I/O condition associated with paging due to a lack of memory on your system.
us: % of CPU time spent in user mode (not using kernel code, not able to acces to kernel resources)
sy: % of CPU time spent in system mode
id: % of CPU time when CPUs is idle
wa: % of CPU time when there was at least one I/O in progress (waiting for finishing that I/O)
pc: physical capacity (how much physical cpu is used)
ec: entitled capacity (in percentage) (it correlates with the system calls (sy))

To measure true idle time measure id+wa together
– if id% is high then likely there is no CPU or I/O problem
To measure cpu utilization measure us+sy together (and compare it to physc):
– if us+sy is always greater than 80%, then CPU is approaching its limits (but check physc as well and in “sar -P ALL” for each lcpu)
– if us+sy = 100% -> possible CPU bottleneck, but in an uncapped shared lpar check physc as well.
– if sy is high, your appl. is issuing many system calls to the kernel and asking the kernel to work. It measures how heavily the appl. is using kernel services.
– if sy is higher then us, this means your system is spending less time on real work (not good)

Dobre lokacije za objašnjavanje ovakvog izlaza su :
Link1 i link2, takođe link3