Red Hat has been heavily involved in the Meltdown and Spectre patch efforts. It also has its initial patches ready well before the originally planned disclosure date of January 9, 2018. Red Hat is also in the unique position that it has the most robust set of open source OS enterprise customers. Those same customers are clamoring for information regarding the performance impacts of the Meltdown and Spectre series of patches.
Red Hat Meltdown and Spectre Patch Performance Impacts
To classify performance impacts of its Meltdown and Spectre patches, Red Hat introduced four basic categories of applications after it tested on Haswell, Broadwell, and Skylake generation servers. Here are the four buckets:
- Measurable: 8-19% – Highly cached random memory, with buffered I/O, OLTP database workloads, and benchmarks with high kernel-to-user space transitions are impacted between 8-19%. Examples include OLTP Workloads (tpc), sysbench, pgbench, netperf (< 256 byte), and fio (random I/O to NvME).
- Modest: 3-7% – Database analytics, Decision Support System (DSS), and Java VMs are impacted less than the “Measurable” category. These applications may have significant sequential disk or network traffic, but kernel/device drivers are able to aggregate requests to moderate level of kernel-to-user transitions. Examples include SPECjbb2005, Queries/Hour and overall analytic timing (sec).
- Small: 2-5% – HPC (High Performance Computing) CPU-intensive workloads are affected the least with only 2-5% performance impact because jobs run mostly in user space and are scheduled using cpu-pinning or numa-control. Examples include Linpack NxN on x86 and SPECcpu2006.
- Minimal: Linux accelerator technologies that generally bypass the kernel in favor of user direct access are the least affected, with less than 2% overhead measured. Examples tested include DPDK (VsPERF at 64 byte) and OpenOnload (STAC-N). Userspace accesses to VDSO like get-time-of-day are not impacted. We expect similar minimal impact for other offloads.
- NOTE: Because microbenchmarks like netperf/uperf, iozone, and fio are designed to stress a specific hardware component or operation, their results are not generally representative of customer workload. Some microbenchmarks have shown a larger performance impact, related to the specific area they stress.
(Source: Red Hat)
Overall, Red Hat tells RHEL customers to expect 1-20% performance impact. The testing was done on RHEL 7 but 6 and 5 should be similar.
The OLTP benchmarks are certainly an area we have seen significant performance impacts in. If you have a database server that spikes above 65% utilization, it is worth looking at whether that server is going to be sufficient post-patches. As previously stated, STH will be providing updated benchmarks as the patches for these vulnerabilities mature. These are not two simple patches but rather a significant series of patches that matter.
Finally, if you are running databases in AWS, GCP, or Azure instances or have databases in VMs, VPS or shared hosting instances, we do suggest looking at your CPU monitoring data. Likewise, these vulnerabilities impact containers (e.g. Dockerized MySQL) as well. For simple web apps, this is not going to be a major impact. On the other hand, if you are running with a smaller resource pool, such as in a NVMe backed VPS or VM, you are going to want to monitor these patches closely.