Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Hi I'm using vmstat to track machine performance during some tests (jmeter). This is virtual machine running on a big machine where lots of other virtual machines are installed (about 20 virtual machines).

I'm using the following software versions:

$ vmstat -V
procps version 3.2.7  

$ uname -a
 Linux cmbpm 2.6.32-042stab044.11 #1 SMP Wed Dec 14 16:02:00 MSK 2011 x86_64 x86_64 x86_64 GNU/Linux

The problem is with results I get, here is a sample (I've converted spaces to single tabs for easier data processing):

procs   -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd    free    buff    cache   si  so  bi  bo  in  cs  us  sy  id  wa  st
 0  0   1506720 6152768 0   824836  1   0   3   2   0   0   0   0   94  6   0
 0  0   1506720 6170744 0   804392  60  64  14  16  0   122651  0   0   98  2   0
 0  1   1506720 6168328 0   801744  145 8   300 52  0   117308  0   0   0   100 0
 0  0   1505688 6173360 0   806852  233 13  1135    478 0   109158  1   0   387 1171860851  0
 0  0   1505172 6168988 0   810140  380 0   0   513 0   117875  0   0   97  3   0

Problem is that some values are much bigger then they should be. Percentage values of CPU time (-----cpu------ section) sometimes greatly exceed 100%. Especially column wa (waiting for data) is problematic (value 1171860851 is extremely strange). Replacing those huge values with zero give reasonable results.

My question is why does it give incorrect values and can it be fixed somehow?
I suspect that virtualization of the machine is a problem here.

share|improve this question
1  
The CPU percentages are reported as percentage of one CPU, if you have more than one core/thread, they can be more than 100%. –  vonbrand Feb 4 '13 at 11:32
    
this bad explanation: 1. most of rows sum up to 100% in your case they should sum up to x*100%, 2. I've point out value of wa=1171860851, does it mean I have 11718608 processors? –  Marek R Feb 4 '13 at 14:37
add comment

1 Answer

up vote 2 down vote accepted

The usual suspects would be:

  1. vmstat may be failing to handle wrapping of counters, counters should not wrap frequently, and it should occur more in user/system/idle than iowait (for normal loads)
  2. vmstat is failing to parse /proc/stat, this may be due directly or indirectly to a 64-bit data type, either overflow or misparse due to wide/missing/merged fields
  3. timewarp is skewing the calculations

The kernel keeps track of user/nice/system/etc as counters (typically 100/CPU), vmstat and other programs calculate averages based on time deltas, e.g. 5 seconds for vmstat 5. Accurate time can be a problem in a virtual environment, though not with such a specific symptom as described (vmstat calculates those numbers using the same timestamp)

Having checked procps/libproc, it reads /proc/stat as long-long integers, and calculates using double precision floats -- I can't see any problems there.

You're running an OpenVZ kernel, you should check that /proc/stats is well-formed, it may be this bug: https://bugzilla.openvz.org/show_bug.cgi?id=1376 You might have better luck parsing /proc/vz/vestat : http://wiki.openvz.org/Vestat

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.