1

Yes, I read that it is normal, but in my case disparity is huge and I can't explain it, just look:

I ran sar command for a while (last lines):

04:53:01 PM     all      0.40      0.00      3.41      0.00      0.00     96.19
04:53:06 PM     all      0.40      0.00      3.01      0.00      0.00     96.59
04:53:11 PM     all      0.80      0.00      3.81      0.00      0.00     95.39
04:53:16 PM     all      1.60      0.00      2.81      0.00      0.00     95.59
04:53:21 PM     all      0.40      0.00      3.21      0.00      0.00     96.39
04:53:26 PM     all      0.80      0.00      2.81      0.00      0.00     96.39
Average:        all      0.76      0.00      2.97      0.01      0.01     96.25

And this is CloudWatch for the same time:

enter image description here

I have cpulimit (https://github.com/opsengine/cpulimit) daemon installed (as described here, adapted to Amazon Linux). I am using micro instance, so that's why I use cpulimit (to avoid throttling). So when I turn it on, the CloudWatch usage jumps to exactly 40%, while top/sar report ±1%. When I turn it off, CloudWatch report ±1% and so does top/sar.

Any ideas here? Is it glitch, or am I using wrong tools (or right tools wrongly)?

Edit: I performed few experiments using this wonderful tool and came to intersting results. Basically CloudWatch CPU % doesn't relate linearly to top CPU %. These are approximate results:

Top% CW%  Steal%
4%   40%  0%
10%  85%  0%
20%  100% 0%
50%  100% 30%

Optimal load is 20%, this is exactly what was described here. The problem is that it renders CloudWatch CPU util useless for micro instance.

0

1 Answer 1

1

You are only allocated a fraction of a CPU. Sar measures your use of the entire CPU and cloudwatch measures your use of the fraction. Judging by the graph you are allocated 0.075 of a CPU.

5
  • Yeah, that is what I thought as well. Are you sure that it is the reason? Because in this case Cloudwatch is basically useless for micro instances. Because measuring 0.075 of CPU doesn't make any sense.
    – Andrey
    Nov 26, 2013 at 22:37
  • What I don't understand why steal time = 0 for both sar and top.
    – Andrey
    Nov 26, 2013 at 22:48
  • Fairly sure that is the reason. You could do some experiments with people.seas.harvard.edu/~apw/stress . However, the other options are that either sar or CloudWatch is incorrect, neither of which I find likely. Nov 27, 2013 at 0:29
  • @Andrey Steal could be zero if the host has light load. Nov 27, 2013 at 0:29
  • People write that maximal load before throttling kicks in is around 20% (real %, by top), but 4% top-time corresponds to 40%. Basically my machine is doing nothing. If it goes to 20% the cloudwatch time will go to 200% and micro instance is single core. I looked into stress, but I think it is not useful enough, because 1) you can't see the effective productivity 2) you can't limit cpu usage. I will write some app in Python to calculate hashes.
    – Andrey
    Nov 27, 2013 at 1:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .