Percona Server scalability on multi-cores serverVadim Tkachenko
We now have hardware in our test lab that represents the next generation of commodity servers for databases. It’s aÂ Cisco UCS C250 server, powered by two Intel Westmere CPUs (X5670 @ 2.93GHz). Each CPU has 6 cores and 12 threads. The most amazing part is the amount of memory. It has 384GB of RAM, whichÂ is actually more space than the disks contain.Â The disks are 270GB in total, with theÂ underlyingÂ configuration RAID10 overÂ eight 2.5″ 15K RPM disks. To make the system even more powerful, I put a FusionIO 320GB SLC card in the PCI-E slot.Â Here isÂ a link to the box specs.
The server was generously provided by Cisco Systems, Inc.
So, obviously I’m anxious to see how Percona Server with XtraDB scales on this hardware, and youÂ can expect a series of benchmarks. An especially interesting topic is what we can get from “threads”, as there are only 12 “real” cores, with each core having two “threads”.
So, I took Percona Server 5.1.47-11.2Â and ran the sysbench oltp read-only and read-write benchmarks using from 1 to 32 threads. The database size was 100 million rows ( about 23GB of data). (Starting withÂ Percona Server 5.1.49-12.0, we are going to provide regular builds dedicated to the Cisco UCS platform)
The full results are available on Wiki, and the graphical representation follows:
You can see from the graph that it scales pretty well even up to 24 threads, despite the fact that half of them are not real CPU cores. For up to 10 threads, theÂ scale factor is quite impressive: it is 8.2 for read-only and 9.2 for read-write.Â Â (I calculate the scale factor as the result with 10 threads divided by the result with 1 thread.) Above 10 threads, theÂ rate of increase is not as large, and for 24 threads we have a scale factor ofÂ 12.6 for read-only and 13.3 for read-write.
Of course, itÂ will beÂ interesting to compare these results with the latest MySQL 5.5 releases, and especially in cases with the number of threads is > 100. I’m going to do these comparisons in my next round of testing.
(Edited by Fred Linhoss)