Reclaim Your CPU (Exemplified by PostgreSQL)

Reclaim Your CPU (Exemplified by PostgreSQL)

posted on January 25, 2017 by Amit Golander

Did you ever stop to think how much of the expensive CPU you purchased actually works for you?

Did you just buy the more expensive CPU (e.g., E5-2699) to be on the safe side?
Maybe you could have saved thousands of dollars and settled for the much cheaper E5-2650?

Several months ago, a grad student from Tel-Aviv University presented at the ICSEE conference an interesting research of what your CPU does for you while running PostgreSQL. I encourage you to go and read the full paper
But I’ll try to summarize some of the interesting PostgreSQL insights here as well.

This analysis also explains the huge savings obtained via reduced Oracle database licensing costs as described in a previous guest post.

What did the analysis reveal about the CPU’s actual activity? Let’s consider the Figure below (originally Figure 3 in the paper). Two storage configurations were compared: XFS with a modern Flash SSD on the left side, versus Plexistor SDM on the right. Please note:
• the effective work (i.e., PostgreSQL database) is marked as User Space%
• the remainder are various types of overhead — System% (Storage and Network services), IOwait% (Storage), and Idle% (Storage, in part)

CPU utilization analysis while running PostgreSQL

One obvious and disappointing conclusion immediately apparent in this chart is that PostgreSQL was only able to extract 13% of the CPU potential, when using XFS — a well-respected file system running in this case in combination with an enterprise-grade SSD.

Let me repeat the bad news – you are only able to effectively use 13% of your CPU investment!

The exact same CPU and operating system using Plexistor SDM did much better. It was able to extract 4.2x more effective work (PostgreSQL) out of the same CPU budget. The CPU was able to process 3.82x more transactions (as per Figure 5 in the original paper), and do so while cutting the response times (under that heavier load) by 3.80x – 6.45x.

This results in happier users (better response time), less stress for DBAs & sysadmins (no performance debugging), and better business outcomes for CxOs (lower CapEx & OpEx).

Oh, and there is nothing in these results which is specific exclusively to PostgreSQL or even to databases. PostgreSQL is just a great example of a Storage-bound application, typical of databases in general. Any I/O-intensive or latency-sensitive application would experience a similar or greater benefit.

Time to reclaim your CPU


Download Request

Please complete all the following fields in the form below:


Contact Us