Tuesday Apr 21, 2009

MySQL 5.4 Scaling on Nehalem with Sysbench

As a final followup to my MySQL 5.4 Scalability on 64-way CMT Servers blog, I'm posting MySQL 5.4 Sysbench results on a Sun Fire X4270 platform using the Intel x86 Nehalem chip (2 sockets/8 cores/16 threads). All CPUs were turned on during the runs. The my.cnf was the same as described in the previous blog.

The Sysbench version used was 0.4.12, and the read-only runs were invoked with the following command:

sysbench --max-time=300 --max-requests=0 --test=oltp --oltp-dist-type=special --oltp-table-size=10000000 \\
   --oltp-read-only=on --num-threads=[NO_THREADS] run

The "oltp-read-only=on" parameter was omitted for the read-write tests. The my.cnf file listed in my previous blog was also used unchanged for these tests.

Here are the results graphically running on Linux.

The read-only results for MySQL 5.4 show a higher peak throughput, but a tail off beyond 32 threads compared to MySQL 5.1. The drop off in throughput is clearly an issue that needs to be tracked down and resolved. By contrast, the read-write results show better throughput across the board for MySQL 5.4 compared to MySQL 5.1 and significantly better scalability.

Here are the MySQL 5.4 results graphically on Solaris (Sysbench 0.4.8). Note that in this case unused CPUs were turned off. The number of vCPUs is the same as the number of active threads up to 16. Active threads beyond 16 are using only 16 vCPUs.

Solaris shows better throughput than Linux for the read-only tests and good scalability across the range of active threads.

The Sun Fire X4270 platform with its Nehalem CPUs offers a clear demonstration of the improved scalability of MySQL 5.4. The results suggest that users can expect to be able to effectively use available CPU resources when running MySQL 5.4 instances on this platform.

Allan

MySQL 5.4 Sysbench Scalability on 64-way CMT Servers

As a followup to my MySQL 5.4 Scalability on 64-way CMT Servers blog, I'm posting MySQL 5.4 Sysbench results on the same platform. The tests were carried out using the same basic approach (i.e. turning off entire cores at a time) - see my previous blog for more details.

The Sysbench version used was 0.4.8, and the read-only runs were invoked with the following command:

sysbench --max-time=300 --max-requests=0 --test=oltp --oltp-dist-type=special --oltp-table-size=10000000 \\
   --oltp-read-only=on --num-threads=[NO_THREADS] run
The "oltp-read-only=on" parameter was omitted for the read-write tests. The my.cnf file listed in my previous blog was also used unchanged for these tests.

Here is the data presented graphically. Note that the number of vCPUs is the same as the number of active threads up to 64. Active threads beyond 64 are using only 64 vCPUs.

And here is some raw data:

Read-only

User ThreadsTxns/secUserSystemIdle
173.0669310
8436.2384160
16855.6483160
321674.6983170
482402.1282171
642727.45701911
802524.69641916
962491.10271856
1282131.09221464

Read-write

User ThreadsTxns/secUserSystemIdle
141.89493021
8269.62621523
16486.14581329
32867.88541234
481121.87491239
641453.00481438
801509.09491536
961612.11541829
1281595.75521830

A few observations:

  • Throughput scales 63% from 32-way to 64-way for read-only and 67% for read-write. Not quite as good as for the OLTP test reported in my earlier blog, but not at all bad.
  • Beyond 48 vCPUs, idle CPU is preventing optimal scaling for the read-only test.
  • There's quite a bit of CPU left on the table for the read-write tests.
There's still a lot more work to be done, but we're definitely seeing progress.

Allan

About

I'm a Principal Engineer in the Performance Technologies group at Sun. My current role is team lead for the MySQL Performance & Scalability Project.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today