Sizing post #5: How to map our existing processing power to new hardware.

In our last blog post “Sizing post #4: How much pain are we willing to tolerate?” we talked about how much pain we can tolerate so we can decide on which percentile we want to size our database workload. It is not a size fits all because it depends on the database workload profile, some databases would be fine with 90th percentile, some others would need 97th, 98th or even 99th percentile.

Once we have decided the number of CPUs required for our database workload we know its footprint and we know more of how the resources are being used. Using this information we can move our database to another hardware and be confident that the target hardware is going to be able to support our database workload.

When we move from a system to another system with different processor or even same processor but different vendor the processing power may not be the same. When we move to a different vendor but the same processor the difference may not be relevant and we could map 1 to 1, meaning, if we know our CPU required is 32, then a target system from different vendor but same processor most likely will be fine with also 32 CPUs, however, if we move to a system with different processor, we most likely need a way to map the number of CPUs required to the new hardware as the processing power may differ greatly.

There could be that the processing power of the new server is more powerful than the existing server. In this case we would need to map the processing power. For example if the new server is twice as powerful then we map 2 to 1. In other words if we had a server where my CPU required is 32, then in the new server I would need 16 CPUs.

On the other hand if the new server has half the processing power of the existing server we map 1 to 2 requiring now 64 CPUs for my imaginary example database workload.

Question is: How to map processing power between existing hardware and new hardware?

Answer: One way to map the existing processing power to a new server processing power is using the RESULT value from SPEC.

“The Standard Performance Evaluation Corporation (SPEC) is a non-profit corporation formed to establish, maintain and endorse a standardized set of relevant benchmarks that can be applied to the newest generation of high-performance computers. SPEC develops benchmark suites and also reviews and publishes submitted results from our member organizations and other benchmark licensees.”

Reference: https://www.spec.org

SPEC has several benchmarks to test the servers. We are using the results from the benchmark called SPEC CPU2006 CINT2006.

“Designed to provide performance measurements that can be used to compare compute-intensive workloads on different computer systems, SPEC CPU2006 contains two benchmark suites: CINT2006 for measuring and comparing compute-intensive integer performance, and CFP2006 for measuring and comparing compute-intensive floating point performance.”

Lets use an example to explain the mapping.

For our example we are using a BL460c Gen9 server as our existing hardware and a DL360 Gen9 as our new hardware.

Source (existing) server: BL460c Gen9
Target (new)      server: DL360  Gen9

SYSTEM                                                       CORES THREADS       CPUs RESULT       RP_CORE      RP_CPU
------------------------------------------------------------ ----- --------- -------- -------- ----------- -----------
ProLiant DL360 Gen9 (2.40 GHz, Intel Xeon E5-2640 v3)        16    2               32 749             46.8        23.4
ProLiant BL460c Gen9 (2.30 GHz, Intel Xeon E5-2699 v3)       18    2               36 678             37.7        18.8

Assume we identified we required 24 CPUs for our database workload when running our database on a BL460c Gen9 server with the Intel Xeon E5-2699 v3 processor, which has a “result per cpu thread” of 18.8.

How many CPU threads are needed in the new DL360 Gen9 with Intel Xeon E5-2640 v3 to cover for those 24 CPUs?

Because the “result per cpu thread” is higher than the one in the existing hardware we can start thinking that we would need less CPUs in the new hardware.

Lets start by answering how much more powerful is the new hardware compared to the existing hardware?

We can answer that by dividing the RP_CPU of the new hardware by the RP_CPU of the existing hardware

  23.4 / 18.8 = 1.24

The new hardware is 1.24 times more powerful than the existing hardware.

In order to get the ratio we divide the RP_CPU of the old hardware by the RP_CPU of the new hardware

  18.8 / 23.4 = 0.8034

Then we multiply the number of required CPUs (24) times the ratio

  24 * (18.8 / 23.4) = 19.28

There is our answer. We need 19.28 CPUs in the new DL 360 server to cover for the 24 CPUs in the existing BL460 server.

Obviously we can’t have fractions of a CPU so we just say 20 CPUs.

24 CPUs in a BL460c    ~    20 CPUs in a DL360

When doing this type of conversion make sure you have the correct precessor because the servers BL460c and DL360 could be configured with several choices and each would make a difference in the “result per cpu thread” of the server.

The value RESULT which is the number that comes out of the benchmark from SPEC is a comparative value among servers. We can divide that to get “result per cpu thread” and be able to come up with an equivalent number of CPUs from one server to another.

Remember that we have been working with required CPUs which is the number of CPUs we found out from looking at and analyzing the standardized ASH/AWR data and that value is representing the database workload, however, we still need to account for headroom for unexpected spikes and potential growth. For example if we required 20 CPUs in our target server DL360 and we want a 30% headroom for unexpected spikes and growth, this means our 20 CPUs represent 70%, in order to get a total we calculate like this

 Total num CPUs =  ( 20 * 100) / 70 = 28.5 ~ 29 CPUs

For our example we would need 29 CPUs

When doing a sizing for the cloud we are going to need the specifications of the server that is in the cloud. If we know our required number of CPUs for our database workload but we don’t know the server model and processor of the hardware used in the cloud it would not be possible to use the SPEC data to map between processing power from source to target servers.

Lets assume that the cloud is using a DL360 Gen9 with Intel Xeon E5-2640 v3 processor. In this case we would look for a service that provides at least the 29 CPUs that we need.

Stay tuned for more on sizing…

Author: Jorge Barba

Leave a comment