Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to figure out how to count read and written bytes per second. At the moment what I'm doing is I read the data from /proc/diskstats which looks like this:

202 0 xvda 80702313 1132334 2823807338 426518304 89838477 177437957 2140229136 1696949080 0 142957364 2123455348

I read the 6th (sectors/s read) and 10th (sectors/s written) fields and multiply them by 512 ( I figured that's the right value by checking the output from fdisk which is saying sectors of 1 * 512 = 512 bytes) which should give me the number of bytes. I take 2 samples and substract the first one from the latter one and then divide the resulting values by the number of seconds in between the samples. It doesn't seem to give the correct results though. Anyone idea on how this should actually be done ? I'm looking for something similar to what sar -b outputs


share|improve this question
Be more specific about "doesn't seem to give the correct results". An example perhaps? – longneck Jan 14 '13 at 18:43

Because you can't compare both of them. sar -b is at specific times, at an interval of 10 minutes or whatever you have specified in your cron job.

But /proc/diskstats is a kernel run time value. It is not calculated at any specific time interval but more of a counter that kernel keeps for accounting. It is from where iostat reads the data. If you specify iostat -xdk 5 5 then, at 5 seconds interval iostat is going to read the /proc/diskstats file and get the weighted average of data from there. Important point to note is that /proc/diskstats is not time dependent and hence you cannot compare it with sar -b which runs at fixed, particular intervals in time.

If you want a more elaborate description, I can check the code and tell but now it is really late in night here.

share|improve this answer
the question is - is my approach correct ? – gyre Jan 14 '13 at 18:58
Use iostat. It is more precise than what you are attempting. iostat -xdk for RHEL6 or iostat -xtk for RHEL5. – Soham Chakraborty Jan 14 '13 at 19:01
Well, I'm pushing the data to Graphite - so I can't really use iostat. I'm taking samples from /proc/diskstats, and pushing them to Graphite where I'm trying to graph the vals/s) – gyre Jan 14 '13 at 19:06
Would collectl be of some help here? – ewwhite Jan 15 '13 at 21:25
yeah, collectctl is proving to be a nice project. It is not included in RHEL channels however, but it is really good for data collection. – Soham Chakraborty Jan 16 '13 at 3:54

Use iostat with interval

iostat -d /dev/xvda <interval(sec)> <counter>

Do iostat in 10sec interval

iostat -d /dev/xvda 10

If you want to get easy output for ploting

iostat -d /dev/xvda 10 | grep xvda

Then it will give you someting like following

xvda               1.30         3.28        38.68    1151011   13583372
xvda              15.00         0.00       100.00          0        100
xvda               0.00         0.00         0.00          0          0
xvda               0.00         0.00         0.00          0          0
xvda               5.00         0.00        32.00          0         32
xvda               0.00         0.00         0.00          0          0
xvda               0.00         0.00         0.00          0          0
xvda               8.00         0.00       240.00          0        240
xvda               0.00         0.00         0.00          0          0

You should always discard the first line because that is the total since machine start or since the counter last wrap around.

I am not sure how difficult to plot with graphite, you can copy and paste them into Excel or LibraOffice Calc and create the chart.

share|improve this answer

Your Answer


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.