Orri Erling's Weblog

Scalability, specifically linear scalability, means that twice the data takes twice as long to process, or that double the gear processes the same data in half the time. This is only literally true for "embarrassingly parallel" workloads.

There are parts of TPC-H which have an embarrassingly parallel nature, like Q1 and Q7. There are parts that are almost as easy, like Q14, Q17, Q19, and Q21, where there is a big scan and a selective hash join with a hash table small enough to replicate everywhere. The scan scales linearly; building the hash does not, since it is done at single-server speed (once in each process). Some queries like Q9 and Q13 end up doing a big cross-partition join which runs into communication overheads.

This is our first look at how performance behaves with bigger data and a larger platform. The results shown here are interesting but are not final. I bet I can do better; by how much is what we'll find out soon enough.

We will here compare a 1000G setup on my desktop, and a 3000G setup at the CWI's Scilens cluster. The former is 2 boxes of dual Xeon E5 2630, and the latter is 8 boxes of dual Xeon E5 2650v2. All things run from memory and both have QDR IB interconnect. Counting cores and clock, the CWI cluster is 6x larger.

As a rough approximation, for the worst queries, 6x the gear runs 3x the data in the same amount of real time. The 1000G setup has near full platform utilization and the 3000G setup has about half platform utilization. In both cases, running two instances of the same query at the same time takes twice as long.

We use Q9 for this study. The plan makes a hash table of part with 1/14 of all parts, replicating to all processes. Then there is a hash table of partsupp with a key of ps_partkey, ps_suppkey, and a dependent of ps_supplycost. This is much larger than the part hash table and is therefore partitioned on ps_partkey. The build is for 1/14th of partsupp. Then there is a scan of lineitem filtered by the part hash table; then a cross-partition join to the partsupp hash table; then a cross partition join to orders, this time by index; then a hash join on a replicated hash table of supplier; then nation; then aggregation. The aggregation is done in each slice; then the slices are added up at the end.

The plan could be made better by one fewer partition crossing. Now there is a crossing from l_orderkey to l_partkey and back to o_orderkey. This would not be so if the cost model knew that the partsupp always hits. The cost model thinks it hits 1/14 of the time, because it does not know that the selection on the build is exactly the same as on the probe.

For the present purposes, the extra crossing just serves to make the matter of interest more visible.

So, for the 1000G setup, we have 43.6 seconds (s) and

Cluster 4 nodes, 44 s. 459 m/s 119788 KB/s  3120% cpu 0%  read 19% clw threads 1r 0w 0i buffers 17622126 68 d 0 w 0 pfs
 

For the 3000G setup, we have 49.9 s and

Cluster 16 nodes, 50 s. 49389 m/s 1801815 KB/s  7283% cpu 0%  read 18% clw threads 1r 0w 0i buffers 135122893 15895255 d 0 w 17 pfs
 

The platform utilization on the small system is better, at 31/48 (running/total threads); the large one has 73/256.

The large case is clearly network bound. If this were for CPU only, it should be done in half the time it takes the small system to do 1000G.

We confirm this by looking at write wait: 3940 seconds of thread time blocked on write over 50s of real time. The figures on the small one are 3.9s of thread time blocked for 39s of real time. The data transfer on the large one is 93 GB.

How to block less? One idea would be to write less. So we try compression; there is a Google snappy-based message compression option in Virtuoso.

We now get 39.6 s and

Cluster 16 nodes, 40 s. 65161 m/s 1239922 KB/s  10201% cpu 0%  read 21% clw threads 1r 0w 0i buffers 52828440 172 d 0 w 0 pfs
 

The write block time is 397 s of thread time over 39 s of real time, 10x better. The data transfer is 50.9 GB after compression. Snappy is somewhat effective for compression and very fast; in CPU profile, it is under 3% of Q9 on the small system. Gains on the small system are less, though, since blocking is not a big issue to start with.

This is still not full platform. But if the data transfer is further cut in half by a better plan, the situation will be quite good. Now we have 102/256 threads running, meaning that there could be another 40-50% of throughput to be added. The last 128 threads are second threads of a core, so count for roughly 30% of a real core.

The main cluster-specific operation is a send from one to many. This is now done by formulating the message to each recipient in a chain of string buffers; then, after all the messages are prepared, these are optionally compressed and sent to their recipient. This is needlessly simple: Compressing can proceed if ever there is a would-block situation on writing. If all the compression is done, then a blocked write should switch to another recipient, and only after all recipients have a would-block situation, then the thread can call-select with all descriptors and block on them collectively. There is a piece of code to this effect, but is not now being used. It has been seen to add no value in small cases, but could be useful here.

The IB fabric has been seen to do 1.8 GB/s bidirectionally on multiple independent point-to-point TCP links. This is about half the nominal 4 GB/s (40 Gbit/s with 10/8 encoding). So the aggregate throughputs that we see here are nowhere near the nominal spec of the network. Lower level interfaces and the occasional busy wait on the reading end could be tried to some advantage. We have not tried 10GbE either; but if that works at nominal speed, then 10GbE should also be good enough. We will try this at Amazon in due time.

In the meantime, there is a 3000G test made at the CWI cluster without message compression. The score is about 4x that of the single server at 300G using the same hardware. The run is with approximately half platform utilization. There are three runs of power plus throughput, the first run being cold.

The numerical quantities summaries follow. One problem of the run is a high peak of query memory consumption leading to slowdown. Some parts should probably be done in multiple passes to keep the peak lower and not run into swapping. The details will have to be sorted out. This is a demonstration of capability; the perfected accomplishment is to follow.

3000G Run 1

Virt-H Executive Summary

Duration of stream execution

Numerical Quantities Summary Timing Intervals in Seconds:

3000G Run 2

Virt-H Executive Summary

Duration of stream execution

Numerical Quantities Summary Timing Intervals in Seconds:

3000G Run 3

Virt-H Executive Summary

Duration of stream execution

Numerical Quantities Summary Timing Intervals in Seconds:

To be continued...

In Hoc Signo Vinces (TPC-H) Series

• In Hoc Signo Vinces (part 1): Virtuoso meets TPC-H
• In Hoc Signo Vinces (part 2): TPC-H Schema Choices
• In Hoc Signo Vinces (part 3): Benchmark Configuration Settings
• In Hoc Signo Vinces (part 4): Bulk Load and Refresh
• In Hoc Signo Vinces (part 5): The Return of SQL Federation
• In Hoc Signo Vinces (part 6): TPC-H Q1 and Q3: An Introduction to Query Plans
• In Hoc Signo Vinces (part 7): TPC-H Q13: The Good and the Bad Plans
• In Hoc Signo Vinces (part 8): TPC-H: INs, Expressions, ORs
• In Hoc Signo Vinces (part 9): TPC-H Q18, Ordered Aggregation, and Top K
• In Hoc Signo Vinces (part 10): TPC-H Q9, Q17, Q20 - Predicate Games
• In Hoc Signo Vinces (part 11): TPC-H Q2, Q10 - Late Projection
• In Hoc Signo Vinces (part 12): TPC-H: Result Preview
• In Hoc Signo Vinces (part 13): Virtuoso TPC-H Kit Now on V7 Fast Track
• In Hoc Signo Vinces (part 14): Virtuoso TPC-H Implementation Analysis
• In Hoc Signo Vinces (part 15): TPC-H and the Science of Hash
• In Hoc Signo Vinces (part 16): Introduction to Scale-Out
• In Hoc Signo Vinces (part 17): 100G and 300G Runs on Dual Xeon E5 2650v2
• In Hoc Signo Vinces (part 18): Cluster Dynamics
• In Hoc Signo Vinces (part 19): Scalability, 1000G, and 3000G (this post)
• In Hoc Signo Vinces (part 20): 100G and 1000G With Cluster; When is Cluster Worthwhile; Effects of I/O
• In Hoc Signo Vinces (part 21): Running TPC-H on Virtuoso Cluster on Amazon EC2