Commit 9744d36
committed
[BREAKING CHANGES] update default
The goal behind this is to provide overall more accurate CPU utilization results. The way we calculate this is to pull the current utilization sleep `n` seconds, poll again, and then take a difference between the two numbers. From my tests at my last organization I found that increasing the sleep time gave more accurate overall results. There are several reasons for this but the main reason is that by the very act of calling up the ruby interpreter you are incuring additional cpu utilization. By increasing the poll interval you allow its utilization to even out from the initial load of the interpreter. `5` is by no means a magic number but I found at my previous employer that `5` was a very reasonable compromise for accuracy and still being able to schedule it to see very granular results. The more resource contrained the machine is the more value you will get out of higher sleep/poll values.
This is a breaking change as it updates the defaults and if you are scheduling this more frequently than 10 seconds (and do not set your own sleep value) you could very easily end up with multiple instances of the same check running which would only increase the problem.
From my tests locally I did not notice much difference (about 2-3% inflated) between the data returned from this check and `top -d 5` values
Signed-off-by: Ben Abrams <[email protected]>sleep for check-cpu.rb
1 parent 59de115 commit 9744d36
2 files changed
+5
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
5 | 5 | | |
6 | 6 | | |
7 | 7 | | |
| 8 | + | |
| 9 | + | |
| 10 | + | |
8 | 11 | | |
9 | 12 | | |
10 | 13 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
53 | 53 | | |
54 | 54 | | |
55 | 55 | | |
| 56 | + | |
56 | 57 | | |
57 | | - | |
| 58 | + | |
58 | 59 | | |
59 | 60 | | |
60 | 61 | | |
| |||
0 commit comments