Quad Core Intel Xeon 53xx Clovertown
by Johan De Gelas on December 27, 2006 5:00 AM EST- Posted in
- IT Computing
MySQL Configuration
To avoid the scaling problems of MySQL, we compiled version 5.0.26 with Peter Zaitsev's Mutex patch. This Patch gives much better scaling and performance using up to four cores. Eight cores and more give variable results. All testing was done with InnoDB as our storage engine in MySQL 5.0.26. Here is our MySQL configuration:
The "query cache" was off, as we wanted to test worst case performance. Our test database is still the same ~1GB database. The workload consists of more than 90% selects, mostly a "read intensive" workload.
MySQL results
All numbers are expressed in queries per second (Y-axis), and the X-axis shows the number of concurrent accesses.
While the Opteron's performance decreases when we add another 4 cores, a second Xeon E5345 pushes the number of queries/s slightly higher. Clearly, MySQL is not ready for more than four cores right now, and it serves as a great reminder for all those with wild "Tens of cores on one die" dreams: making software scale with massive multi-core systems is and will never be easy. Below you can see the scaling of MySQL running on one Xeon 5160 (one core disabled), two (one CPU) and four (Dual CPU configuration).
For those running MySQL, clock speed still rules. One 3GHz Xeon 5160 is already capable of no less than 1000-1100 queries/s. Compare this with the clock speed scaling (1 core):
You can see that a 28% higher clock speed results in 28% higher performance. We can conclude that clock speed still matters, and that it is often much harder to get more performance out of multiple cores, even in applications that are relatively easy split up into threads.
Although our current DB2 results are "beta" and not ready for publication, we can already say now that DB2 is slower than MySQL but scales much better. We get an 80% increase from 2 to 4 cores.
To avoid the scaling problems of MySQL, we compiled version 5.0.26 with Peter Zaitsev's Mutex patch. This Patch gives much better scaling and performance using up to four cores. Eight cores and more give variable results. All testing was done with InnoDB as our storage engine in MySQL 5.0.26. Here is our MySQL configuration:
| MySQL Configuration | |
| default-storage-engine | InnoDB |
| skip-external-locking | |
| skip-locking | |
| key_buffer | 256M |
| . | |
| table_cache | 64 |
| max_allowed_packet | 1M |
| thread_stack | 128K |
| . | |
| sort_buffer_size | 2M |
| read_buffer_size | 2M |
| innodb_buffer_pool_size | 1G |
| . | |
| thread_concurrency | 16 |
| innodb_thread_concurrency | 16 |
| innodb_additional_mem_pool_size | 8MB |
| read_rnd_buffer_size | 8MB |
| thread_cache | 64 |
| max_heap_table | 256MB |
| tmp_table | 128MB |
| . | |
| innodb_log_file_size | 250MB |
| innodb_table_locks | 0 |
| innodb_flush_log_at_trx_commit | 0 |
| max_user_connections | 2000 |
| max_connections | 2000 |
The "query cache" was off, as we wanted to test worst case performance. Our test database is still the same ~1GB database. The workload consists of more than 90% selects, mostly a "read intensive" workload.
MySQL results
All numbers are expressed in queries per second (Y-axis), and the X-axis shows the number of concurrent accesses.
While the Opteron's performance decreases when we add another 4 cores, a second Xeon E5345 pushes the number of queries/s slightly higher. Clearly, MySQL is not ready for more than four cores right now, and it serves as a great reminder for all those with wild "Tens of cores on one die" dreams: making software scale with massive multi-core systems is and will never be easy. Below you can see the scaling of MySQL running on one Xeon 5160 (one core disabled), two (one CPU) and four (Dual CPU configuration).
| MySQL Core Scaling | |||
| Concurrency | 1 core | 2 cores | 4 cores |
| 5 | 735 | 900 | 1082 |
| 10 | 826 | 1082 | 1267 |
| 25 | 823 | 1105 | 1323 |
| 50 | 780 | 1109 | 1319 |
| 100 | 689 | 1075 | 1196 |
For those running MySQL, clock speed still rules. One 3GHz Xeon 5160 is already capable of no less than 1000-1100 queries/s. Compare this with the clock speed scaling (1 core):
| MySQL Clock Scaling | ||
| Concurrency | 2.33 GHz | 3 GHz |
| 5 | 568 | 735 |
| 10 | 647 | 826 |
| 25 | 619 | 823 |
| 50 | 579 | 780 |
| 100 | 531 | 689 |
You can see that a 28% higher clock speed results in 28% higher performance. We can conclude that clock speed still matters, and that it is often much harder to get more performance out of multiple cores, even in applications that are relatively easy split up into threads.
Although our current DB2 results are "beta" and not ready for publication, we can already say now that DB2 is slower than MySQL but scales much better. We get an 80% increase from 2 to 4 cores.
Facebook
Twitter
RSS
15 Comments
View All Comments
zsdersw - Friday, December 29, 2006 - link
Smithfield/Paxville is a MCM chip (two pieces of silicon in one package), as well.
Khato - Wednesday, December 27, 2006 - link
Agreed on it being quite the good review, save for the lack of power consumption numbers/analysis. Form factor and power consumption can be just as important as the performance when the application can be spread across multiple machines, now can't it? At the very least, it would be nice to link to the power consumption numbers for the opteron platform in the first review it showed up in (which puts the dual clovertown at 365W load, while the quad 880 is supposedly 657W load.)rowcroft - Wednesday, December 27, 2006 - link
Loved the article, great job.I'm in the process of purchasing two dual quad core servers for VMWare use. Looking at the cost to performance analysis, it would be worth mentioning that many of the high end applications are licensed on a per socket basis. This alone is saving us $20,000 on our VMWare license and making it a compelling solution.
I would love to see more of this type of article as well- very interesting and not something you can easily find elsewhere on the net. (Tom's hardware reviewed the chip running XP Pro!)
duploxxx - Friday, December 29, 2006 - link
If you think that reading this review will help you to decide what to buy as VMWARE base you are going the wrong way! Yes these small tests are in favor for the new MCW architecture as we saw before and since haevy workload seems hard to test for some sites like anand! keep in mind that VMWARE is heavy workload, you combine the cpu and ram to whatever you want, guess what the fsb can't be combined like you wish!thinking that a 2x quad will outperform the 4p opteron is a big laugh! the fsb will kill youre whole ESX instantly from 4+ os on your system with normal load.
the money you save is indeed for sure, the power you loose is an other thing!
friendly info from a certified esx 3.0 beta tester :)
Viditor - Wednesday, December 27, 2006 - link
Probably one of your most thorough and well-rounded articles Johan...many thanks!It was nice to see you working with large (16GB) memory.
If you do get a Socket F system, will you be updating the article?