Effect of Intel's power management on webservers
Tags: hasura, performance, intel, powermanagement
Published: 2020-04-14 19:51:37

---
title: Effect of Intel's power management on webservers
published: true
date: 2020-04-14 16:32:49 UTC
tags: Hasura, performance, intel, powermanagement
canonical_url: https://hasura.io/blog/effect-of-intels-power-management-on-webservers/
---

![](https://hasura.io/blog/content/images/2020/04/Hasura_Perf_2--1-.jpg)

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](https://hasura.io/blog/decreasing-latency-noise-and-maximizing-performance-during-end-to-end-benchmarking/) by [Brandon](https://github.com/jberryman). This blogpost explains that post from a layman’s perspective.

<!--kg-card-begin: html-->
# Background
<!--kg-card-end: html-->

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](https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt) 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](https://software.intel.com/en-us/articles/power-management-states-p-states-c-states-and-package-c-states) 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](https://manpages.debian.org/testing/linux-cpupower/turbostat.8.en.html) explains the various fields that turbostat will output.

<!--kg-card-begin: html-->
# Processor states while Hasura serves a GraphQL Request 
<!--kg-card-end: html-->

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](https://github.com/giltene/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

```
<figcaption>Latency measurement for Hasura serving a simple GraphQL request</figcaption>

Here's the output from turbostat:

<!--kg-card-begin: html-->
```
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
```
<!--kg-card-end: html-->

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.

<!--kg-card-begin: html-->
# Fine tuning processor states 
<!--kg-card-end: html-->
### "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

```
<figcaption>Latency measurement with performance governor enabled</figcaption>

We see better latencies at pretty much every percentile.

**turbostat output:**

<!--kg-card-begin: html-->
```
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
```
<!--kg-card-end: html-->

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

```
<figcaption>Latency measurement with performance governor enabled and idle states disabled</figcaption>

Again we can see an improvement at almost every percentile.

Turbostat output:

<!--kg-card-begin: html-->
```
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
```
<!--kg-card-end: html-->

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

<!--kg-card-begin: html-->
# Conclusion 
<!--kg-card-end: html-->

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](https://mobile.twitter.com/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