Effect of Intel's power management on webservers

While benchmarking some tweaks to Hasura we noticed some strange behavior. We were measuring latencies for a simple GraphQL request being served by Hasura. Surprisingly Hasura was performing better when there was more load on the system than otherwise.

At 100 requests per second the processor load was low enough that the processor going to sleep was negatively impacting the latency measurements. However, when a browser was open on the same machine, latency measurements improved!

The explanation for this is quite intriguing and is documented in detail in this post by Brandon. This blogpost explains that post from a layman’s perspective.

Background

Modern Intel processors have extremely sophisticated power management that modifies the clock frequency and powers up and down subsystems dynamically and constantly. This can happen several times a second.

p-states and c-states

Power management happens both when the processor is idle and otherwise. Idle states of a processor are called C-states and are denoted as C0, C1, C2... C0 is the operating state whereas C1, C2, C3.. are states where some or more of the subsystems are shutdown. Generally the higher the C-state the lower the power consumption but also the longer it takes for the processor to move back to the operating state C0.

We can look at the idle states available on my laptop using the cpupower command:

$ cpupower idle-info
CPUidle driver: intel_idle
CPUidle governor: menu
analyzing CPU 0:

Number of idle states: 9
Available idle states: POLL C1 C1E C3 C6 C7s C8 C9 C10
POLL:
Flags/Description: CPUIDLE CORE POLL IDLE
Latency: 0
Usage: 5845
Duration: 3482887
C1:
Flags/Description: MWAIT 0x00
Latency: 2
Usage: 155904
Duration: 40263250
C1E:
Flags/Description: MWAIT 0x01
Latency: 10
Usage: 505874
Duration: 163384145
C3:
Flags/Description: MWAIT 0x10
Latency: 70
Usage: 405130
Duration: 115592556
C6:
Flags/Description: MWAIT 0x20
Latency: 85
Usage: 2407019
Duration: 1503034108
C7s:
Flags/Description: MWAIT 0x33
Latency: 124
Usage: 657
Duration: 674710
C8:
Flags/Description: MWAIT 0x40
Latency: 200
Usage: 1694254
Duration: 2067037470
C9:
Flags/Description: MWAIT 0x50
Latency: 480
Usage: 38
Duration: 65699
C10:
Flags/Description: MWAIT 0x60
Latency: 890
Usage: 44032
Duration: 79069478

We can see that my processor has these idle states available: POLL, C1, C1E, C3, C6, C7s, C8, C9, C10. We can also see a Latency field that tells us the maximum time (in µs) the processor will take to go from that state to the operating C0 state. It is possible to enable/disable these states using the cpupower idle-set command.

Similarly when a processor is not idle it will be in one of several P-states denoted by P0, P1, P2, P3. The higher the p-state, the lower the voltage and operating frequency of the processor. This means CPU bound programs will in general execute faster in a lower P-state than a higher p-state. We cannot explicitly set the processor to a particular state. However we can set a CPUFreq governor using the cpupower frequency-set -g <governor> command.

On my laptop I can see the available governors with:

$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.00 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.00 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.60 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

We can see that I can set the governor to performance or powersave and the current governor is powersave.

This article explains the various P-states and C-states that intel processors implement in greater detail.

We can also measure the time spent by the processor in various states using the turbostat command:

$ sudo turbostat --quiet sleep 5
5.004098 sec
Core    CPU Avg_MHz Busy%   Bzy_MHz TSC_MHz IRQ SMI C1  C1E C3  C6  C7s C8  C9  C10 C1% C1E%    C3% C6% C7s%    C8% C9% C10%    CPU%c1  CPU%c3  CPU%c6  CPU%c7  CoreTmp PkgTmp  GFX%rc6 GFXMHz  Totl%C0 Any%C0  GFX%C0  CPUGFX% Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 PkgWatt CorWatt GFXWatt RAMWatt PKG_%   RAM_%
-   -   6   0.35    1640    1991    2009    0   1   54  11  78  0   1555    0   523 0.00    0.01    0.00    0.18    0.00    27.94   0.00    71.50   0.95    0.00    0.30    98.39   54  55  99.96   300 2.76    1.83 0.00   0.00    20.55   0.12    0.09    0.15    75.31   0.00    0.00    0.76    0.09    0.00    0.32    0.00    0.00
0   0   12  0.77    1625    1991    730 0   0   2   5   48  0   603 0   90  0.00    0.00    0.01    0.98    0.00    47.68   0.00    50.57   1.25    0.00    0.90    97.07   54  55  99.96   300 2.76    1.83    0.00    0.00    20.56   0.12    0.09    0.15    75.31   0.00    0.00    0.76    0.09    0.00    0.32    0.00    0.00
0   4   4   0.25    1650    1991    154 0   0   0   0   4   0   125 0   70  0.00    0.00    0.00    0.07    0.00    22.48   0.00    77.17   1.77
1   1   2   0.15    1689    1991    95  0   0   8   0   3   0   66  0   32  0.00    0.01    0.00    0.05    0.00    9.76    0.00    90.01   0.86    0.00    0.08    98.91   54
1   5   6   0.35    1626    1991    222 0   0   0   0   4   0   129 0   115 0.00    0.00    0.00    0.06    0.00    18.13   0.00    81.44   0.67
2   2   5   0.31    1672    1991    187 0   0   1   0   6   0   163 0   53  0.00    0.00    0.00    0.10    0.00    39.79   0.00    59.78   1.02    0.01    0.13    98.53   54
2   6   8   0.50    1623    1991    299 0   0   1   6   5   0   246 0   61  0.00    0.00    0.01    0.08    0.00    46.01   0.00    53.39   0.84
3   3   4   0.27    1642    1991    180 0   0   5   0   5   0   139 0   43  0.00    0.01    0.00    0.07    0.00    29.59   0.00    70.05   0.58    0.00    0.10    99.06   54
3   7   3   0.19    1664    1992    142 0   1   37  0   3   0   84  0   59  0.00    0.05    0.00    0.05    0.00    10.11   0.00    89.58   0.66

In the above output we can see that the processor spends < 0.5% in C0 state (Busy%) because we are executing the sleep command and there is not much else happening on the machine. The bulk of the time is spent in C7 state (CPU%c7). This man page explains the various fields that turbostat will output.

Processor states while Hasura serves a GraphQL Request

How does all of this affect Hasura's performance you ask? Let us look at power management states of the machine while Hasura executes a simple GraphQL query. The below measurements were made on my laptop running Intel i7-8550U (1.8GHz turbo boost to 4GHz).

Both Hasura and Postgres were running on the same machine and a simple GraphQL query fetching about 5 rows was used. I've used wrk2 - launched using turbostat - to run a constant load of 100RPS.

Here's the output from the wrk2 command:

Running 1m test @ http://localhost:8181/v1/graphql
  1 threads and 10 connections
  Thread calibration: mean lat.: 2.489ms, rate sampling interval: 10ms
  Thread Stats Avg Stdev Max +/- Stdev
    Latency 2.49ms 521.70us 12.94ms 75.29%
    Req/Sec 105.63 102.66 363.00 37.27%
  Latency Distribution (HdrHistogram - Recorded Latency)
 50.000% 2.52ms
 75.000% 2.80ms
 90.000% 3.03ms
 99.000% 3.53ms
 99.900% 5.90ms
 99.990% 12.94ms
 99.999% 12.94ms
100.000% 12.94ms

Latency measurement for Hasura serving a simple GraphQL request

Here's the output from turbostat:

60.011521 secCoreCPUAvg\_MHzBusy%Bzy\_MHzTSC\_MHzIRQSMIC1C1EC3C6C7sC8C9C10C1%C1E%C3%C6%C7s%C8%C9%C10%CPU%c1CPU%c3CPU%c6CPU%c7CoreTmpPkgTmpGFX%rc6GFXMHzTotl%C0Any%C0GFX%C0CPUGFX%Pkg%pc2Pkg%pc3Pkg%pc6Pkg%pc7Pkg%pc8Pkg%pc9Pk%pc10PkgWattCorWattGFXWattRAMWattPKG\_%RAM\_%--503.0016691992700090261197115261101734710074176980.010.040.061.620.0249.450.0045.855.200.072.6389.103940100.0030024.3820.600.000.0025.921.420.420.1147.070.000.001.150.460.000.430.000.0000503.08162919928822032210185122589399220050.000.030.051.390.0351.970.0043.495.230.072.5689.073940100.0030024.3820.600.000.0025.921.420.420.1147.070.000.001.150.460.000.430.000.0004503.07161519929119049259216152359173021200.000.040.061.810.0348.680.0046.355.2411603.29180719928405020171191120108406020560.010.020.061.350.0049.630.0045.674.860.072.4289.363915452.75165319928734039385191138488161024980.000.070.051.640.0244.750.0050.755.4022523.15164419929181029269184143639256020080.000.070.061.700.0250.970.0044.075.190.072.4989.103926532.99175619927914025265183113828432022480.010.030.051.340.0149.800.0045.805.3533452.80161619928336025209150140168112026630.000.050.051.660.0244.790.0050.685.200.073.0688.883937462.851617199294980422032261709210068221000.010.030.062.120.0055.000.0239.955.14

We can see the processor was busy i.e in C-state 0 less than 3.5% of the time, while it spent about 90% of the time in the deep C-7 state, which is slow to wake and do useful work.

Essentially at 100 RPS Hasura takes so little of the processor time that the processor spends most of the time in deep sleep 🤓 That in turn increases the latency of requests because it takes time for the processor to wake up and serve the request.

Fine tuning processor states

"performance" p-state governor

How does using the performance governor improve the situation? Switching it to performance mode with...

$ sudo cpupower frequency-set -g performance

...reduces latency as the CPU is more ready to ramp up and do work when it comes:

wrk2 output:

Running 1m test @ http://localhost:8181/v1/graphql
  1 threads and 10 connections
  Thread calibration: mean lat.: 2.002ms, rate sampling interval: 10ms
  Thread Stats Avg Stdev Max +/- Stdev
    Latency 1.94ms 579.10us 9.26ms 68.44%
    Req/Sec 105.33 100.88 333.00 43.93%
  Latency Distribution (HdrHistogram - Recorded Latency)
 50.000% 1.90ms
 75.000% 2.34ms
 90.000% 2.62ms
 99.000% 3.21ms
 99.900% 5.98ms
 99.990% 9.27ms
 99.999% 9.27ms
100.000% 9.27ms

Latency measurement with performance governor enabled

We see better latencies at pretty much every percentile.

turbostat output:

60.006307 secCoreCPUAvg\_MHzBusy%Bzy\_MHzTSC\_MHzIRQSMIC1C1EC3C6C7sC8C9C10C1%C1E%C3%C6%C7s%C8%C9%C10%CPU%c1CPU%c3CPU%c6CPU%c7CoreTmpPkgTmpGFX%rc6GFXMHzTotl%C0Any%C0GFX%C0CPUGFX%Pkg%pc2Pkg%pc3Pkg%pc6Pkg%pc7Pkg%pc8Pkg%pc9Pk%pc10PkgWattCorWattGFXWattRAMWattPKG\_%RAM\_%--671.723930199267347022716481301913532725852171620.010.040.081.620.0150.840.0045.668.010.102.2387.954949100.0130013.7311.580.000.0019.861.410.350.0452.640.000.002.491.690.000.640.000.0000621.58392319929298034167175127739688019670.020.050.081.920.0154.270.0042.067.760.072.1788.424949100.0130013.7311.580.000.0019.861.410.350.0452.640.000.002.491.690.000.640.000.0004641.6439241992766203619614491728251021330.000.020.061.190.0147.090.0049.977.6911711.81393219928996026232196125349553120350.000.050.091.730.0153.370.0042.928.420.082.2587.444615681.74393319928754035224136113259662022930.020.040.061.590.0153.980.0042.548.4822701.78393719927611020200149106338247022600.000.020.081.530.0047.710.0048.857.350.081.7889.014726601.5439181992792002521013478028559119930.000.040.061.050.0151.940.0045.337.5833741.88393719928414025259164126239352020640.000.100.071.780.0249.070.0047.058.320.162.7286.914837691.763930199286920261602031451109273024170.000.030.172.160.0149.290.0046.568.45

Notice Bzy_MHz is now close to the maximum advertised frequency of 4GHz (with turboboost).

Prohibit idle states

We can keep the processor from entering deep sleep states with:

$ sudo cpupower idle-set -D2

This will disable any idle state with a latency >= 2µs which on my laptop is all idle states.

Here's the results from wrk2:

Running 1m test @ http://localhost:8181/v1/graphql
  1 threads and 10 connections
  Thread calibration: mean lat.: 0.995ms, rate sampling interval: 10ms
  Thread Stats Avg Stdev Max +/- Stdev
    Latency 1.13ms 353.31us 8.95ms 79.16%
    Req/Sec 108.45 104.68 333.00 19.19%
  Latency Distribution (HdrHistogram - Recorded Latency)
 50.000% 1.20ms
 75.000% 1.32ms
 90.000% 1.41ms
 99.000% 1.79ms
 99.900% 4.33ms
 99.990% 8.96ms
 99.999% 8.96ms
100.000% 8.96ms

Latency measurement with performance governor enabled and idle states disabled

Again we can see an improvement at almost every percentile.

Turbostat output:

60.005077 secCoreCPUAvg\_MHzBusy%Bzy\_MHzTSC\_MHzIRQSMIC1C1EC3C6C7sC8C9C10C1%C1E%C3%C6%C7s%C8%C9%C10%CPU%c1CPU%c3CPU%c6CPU%c7CoreTmpPkgTmpGFX%rc6GFXMHzTotl%C0Any%C0GFX%C0CPUGFX%Pkg%pc2Pkg%pc3Pkg%pc6Pkg%pc7Pkg%pc8Pkg%pc9Pk%pc10PkgWattCorWattGFXWattRAMWattPKG\_%RAM\_%--368599.76369319926809116000000000.000.000.000.000.000.000.000.000.240.000.000.00858499.92300398.3899.590.000.000.000.000.000.000.000.000.0019.7318.800.000.350.000.0000368599.763693199292922000000000.000.000.000.000.000.000.000.000.240.000.000.00818499.92300398.3899.590.000.000.000.000.000.000.000.000.0019.7318.800.000.350.000.0004368599.763693199271302000000000.000.000.000.000.000.000.000.000.2411368599.763693199291782000000000.000.000.000.000.000.000.000.000.240.000.000.008015368599.763693199295412000000000.000.000.000.000.000.000.000.000.2422368599.763693199279252000000000.000.000.000.000.000.000.000.000.240.000.000.008526368599.763693199283442000000000.000.000.000.000.000.000.000.000.2433368599.763693199297892000000000.000.000.000.000.000.000.000.000.240.000.000.008037368599.763693199268922000000000.000.000.000.000.000.000.000.000.24

As expected the Busy% is now close to the 100%.

Conclusion

In this article we have seen that processor power management has significant effect on response times with Hasura. Using the performance governor and disabling idle states improves the average latency by almost 50%. A couple of caveats to be aware of though:

• With wrk2's, measured latencies are [only] accurate to a +/- ~1 ms granularity, due to OS sleep time behavior.
• Disabling idle states/using the performance governor has the effect of also consuming more power. In particular disabling all idle states means that the CPU is running at peak frequency continuously. You might want to experiment with disabling some of the deeper C-states and leaving the shallower ones on.

We have also not tried these in production and these are not official recommendations. However, if you do try these techniques out, tweet to us at @HasuraHQ or join us on Discord for more discussions on Hasura & GraphQL! --> discord.gg/hasura

Sign up for our newsletter to know when we publish new articles. --> http://eepurl.com/dBUfJ5