2011年9月13日 星期二

Oracle MySQL/Linux/Virtual Machine (LVM) Integrated Demo Script

Objective
To show that MySQL runs on top of Oracle Virtual Machine and Oracle Enterprise Linux would maximize the value for the customers by offering the lowest total cost of ownership, the highest performance, scalability and productivity. This Oracle LVM integrated demo includes several software/techinques from Oracle, they are MySQL Enterprise Monitor, MySQL Database, MySQL replication, MySQL Proxy, Oracle Virtual Machine, Oracle Virtual Machine Template and Oracle Linux. Those products would bring the following the users:
MySQL Enterprise Monitor helps MySQL DBA managing the database, improving performance, and increase DBA's skill. It maximize the SLA of the database and help the DBAs increase their productivity.
MySQL Proxy enable scale out solution by offering read-write splitting features in the most cost effective manner.
MySQL replication helps the user increase availability and capacity of the database in a lowest cost.
The user would enjoin the best performance by adopting MySQL on top of Oracle Enterprise Linux.
Oracle Virtual Machine template for MySQL increase the productivity of the DBA by per-configured/optimized MySQL database, and decrease the resource needed for deploying MySQL.
Oracle Virtual Machine would help the users with maximize HA from virtual machine layer, it helps MySQL application get zero down time, when migrating the virtual machine between different servers.

Demo Environment

The Servers of the Demo Environment
Install and Configure the Demo Environment
As above graph shows, we apply 3 physical servers – ovmm, ov1, ovs2, ovmm contains OVM Mangaer, PHP pages that act as MySQL client application, and MySQL Enterprise Monitor, ovs1 and ovs2 need to be registered on Oracle Virtual Machine manager as virtual machine server, ovs2 contains one virtual machine for master database, and one virtual machine for first slave, ovs2 contains one virtual machine for 2nd slave database, and ovs2 also act as the backup server for the master database, we will demo the fail-over features by live migration on the Virtual Machine layer. The details of install OVM with HA please refer the document http://www.rachelp.nl/userfiles/file/Create_oraclevm_haserverpool.pdf and. There are several points need to take care of while installing the environment, I list them as below:
For high availability from the virtual machine layer, we need to configure HA options with OVM servers pool on OVM manager, and the servers that support HA need to attach to a shared storage, in this case, it is NFS, and we need to add read_write, sync, and no_root_squash options when doing NFS export, refer http://download.oracle.com/docs/cd/E15458_01/doc.22/e15440/toc.htm#BABDEFDG for the details.
MySQL virtual machine template will runs firewall when ever is started, we need to turned if off manually.
To enable replication and MySQL Enterprise Monitor Agent, the time lag between each virtual machine servers could not larger than a certain period, for say 15 seconds.
The available space on the shared storage need to larger than 70 GB.
For some cases when restart virtual machine the option file - /etc/my.cnf could reset to the default value.
Demo Flow
1 Show MySQL, OVM, Oracle Linux, Oracle Virtual Machine, Oracle Virtual Machine Template for MySLQ download address on Oracle eDelivery.
2 OVM/OEL Demo
  • Navigate OVM interface.
  • Create/Initiate virtual machine with Oracle Virtual Machine Template for MySQL (the template was imported on the “Resource” tab).
OVM template for MySQL offers the users with a configured/tuned MySQL environment, we do not need to tune MySQL options and it can be a base for customized template to foster the deploying speed. For example, we can create template for slave servers from the standard OVM template for MySQL, so we can easily extend the capacity by adding more slave servers from the customized OVM MySQL slave template.3 MySQL Demo
  • Show slide 17 of MySQL technical presentation, explain the demo scenario to the audience
  • Show MySQL master on 10.186.122.69
ssh root@10.186.122.69, password: “oracle”
login MySQL master server, with username “root” and pssword “oracle” by
mysql -h 10.186.122.69 -P 3306 -u root -p oracle
use world;
show tables;
select code, name, continent, population, gnp from Country;
  • Show MySQL slave 1 on 10.186.122.72 and slave 2 on 10.186.122.174
login MySQL slave 1 with usrname “root”, password “oracle”
mysql -h 10.186.122.72 -P3306 -u root -p oracle
show slave status\G
use world;
show tables;
select code, name, continent, population, gnp from Country;
login MySQL slave 1 with usrname “root”, password “oracle”
mysql -h 10.186.122.174 -P3306 -u root -p oracle
show slave status\G
use world;
show tables;
select code, name, continent, population, gnp from Country;
  • Show MySQL Proxy on ovmm.sg.oracle.com
ssh root@ovmm.sg.oracle.com, password “Pass0rd”
ps -ef | grep proxy (show MySQL Proxy command)
  • Show PHP demo application source code on ovmm.sg.oracle.com
vi /var/www/html/worldApp/application/phpQueryPage.php and /var/www/html/worldApp/application/phpUpdatePage.php
high light the code of
$con = mysql_connect("127.0.0.1:4040", "root", "oracle");
show the audience that the database connection is through MySQL Proxy, and read-write splitting is accomplished by this service.
  • Display phpQueryPage page from browser, the URL is below:
http://ovmm.sg.oracle.com/worldApp/application/phpQueryPage.php
show audience the host name on the page, it will change to the other slave when the current slave server is down (it shows slave 1 at this moment)
shutdown slave 1 (shutdown virtual machine – slave 1 is an approach that close to the real case, but it take more time, shutdown database would be fast, it should be easier to keep the pace of demo)
show audience the host name on the page, it had changed to the slave 2 at this moment
  • Demo the master slave replication feature by:
Show phpUpdatePage.php
Query the data by type “HKG” in the “Code” field, and press enter
Insert one record by changing the “Code” field form “HKG” to “ABX”, and press “Insert” button, and query the new record out by type “ABX” on the “Code” filed then press “Query” button.
Back to phpQueryPage.php, the country code “ABX” shows on the query page
  • Demo the live migration feature, and MySQL HA supported by the feature
Ping 10.186.122.69 from ovmm.sg.oracle.com, show the response and message sequence numbers displayed on the terminal
Live migration from OVM interface, from OVM manager by pick “Live Migration” from the “More Action” list.

Show “ping ”, there is a gap with the message sequence number from the ping output after live migration, but the interruption is very small (less than 2 seconds)
Show the message sequence number leap, but the phpUpdatePage.php works fine after live migration, the user interface has no interruption for the migration on the virtual machine layer.

2011年5月8日 星期日

Benchmark MySQL 5.5.9 on Oracle Sun X4170 M2

As I posted the testing result from MySQL on HP server (refer to the previous benchmark), my colleagues from Oracle System Practice are very interesting in MySQL performance on Sun's x86 servers (of course we hope we can proof the servers from Oracle are superior than HP). With the help from our VAD partner - Bestcom, we got a Sun X7140 M2 installed in our data center, thanks for the endeavor form my colleague Cano Lai, the server was setup and and ready for testing very soon.

Technical Specification

The configuration of the system as below:

Server


  • CPU: 6 Core Intel E5640 * 2, 2 threads with each core, 12 Cores/24 Threads in total
  • Memory: 16G Bytes
  • Hard Disk: 146GB * 2

Operating System

Red Hat Enterprise Linux 5.6, with base kernel ( Linux Kernel 2.6.18-238.el5 ) 1st run, Oracle Enterprise Kernel ( Linux Kernel 2.6.32-100.26.2 el5) for the 2nd run.

Database

MySQL 5.5.9 Community Edition with InnoDB storage engine

Tasks


  • Setup Sun X4170 M2
  • Install Red Hat Linux 5.6
  • Install MySQL 5.5.9
We downloaded MySQL for Red Hat & Oracle Enterprise Linux 5 (x86, 64-bit) from MySQL download site, apart from MySQL server, shared component is needed for compiling Sysbench.
  • Install Sysbench 0.4.12
Following the installion steps on Sysbench web site http://sysbench.sourceforge.net/docs/#install, would get things done easily, the only thing that need to take care of is to install MySQL shared component in advanced, and let the software and libraries should be accessible.
  • Tune MySQL
Some of tuned options in my.cnf file are list as below:

# The number of threads might be more than 1000, set to 1500 to accommodate it
max_connections = 1500
# The server has 16 GB RAM, evaluate the overhead from OS and Sysbench,
# 12 GB innodb buffer pool, could be fully utilize the available memory
innodb_buffer_pool_size = 12G
# Multiple innodb buffer pools could reduce contention for some of resources such as
# free lists, flush lists, LRUs and buffer pool mutex
innodb_buffer_pool_instance=3
# New file format from MySQL 5.5
innodb_file_format=Barracuda
innodb_file_per_table
# Increase the number of threads for writing dirty pages
innodb_write_io_threads = 8
# Increase the number of I/O threads for read operations
innodb_read_io_threads = 8
# Increase the number of innodb_thread_concurrency to fully utilize the multiple
# cores/threads environment
innodb_thread_concurrency = 24
# innodb_flush_log_at_trx set to 1, InnoDB will flush (fsync) the transaction logs to the
# disk at each commit, which offers full ACID behavior. This a conservative approach.
# If set this to 0 or 2 might reduce disk I/O and increase the measurements of the test.
innodb_flush_log_at_trx_commit = 1

  • Test against MySQL on Red Hat 5.6 based kernel with Sysbench
The following command would generate data for the test, we had 100 million rows in the largest table.

nohup sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=100000000 --mysql-user= --mysql-password= prepare

Execute the test with the following command, and collect the test results from the outputs of nohup

nohup sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=100000000 --num-threads= --mysql-user= --mysql-password= run
  • Substitute Red Hat 5.6 based kernel with Oracle Enterprise Linux Kernel
Apart from MySQL performance on Oracle server, we were curious if there is any difference between the Based Kernel and Oracle Unbreakable Kernel. There was time available after the 1st run, we decided to have the same benchmark on the 2nd run which had the same configuration with the previous run, but replace the OS kernel with Oracle UEK. To upgrade the kernel is not a difficulty job, the required command as below:

# cd /etc/yum.repos.d/
# wget http://public-yum.oracle.com/public-yum-ol6.repo
# wget http://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol6
# yum -y install kernel-*

After reboot the server, you will see the kernel had been upgraded with the following command:

# uname -a
# yum info kernel-uek
  • Test against MySQL on Oracle Enterprise Kernel
The steps are the same as task 6.
  • Consolidate the testing results Collect the number of read/write and transactions with each run, and generate line charts.
Testing Results

The benchmark result summarized as chart 1 and Chart 2, for the scale of transaction per second was too small, I created the 3rd chart to depict it.

  • Chart 1 is the measurement for read-only transaction, MySQL on OEL got more than 54,000 operations at 900 threads while with everything the same except Red Hat, we got around 20,000 read-only operations and down to 11,000 at 900 threads.
  • In Chart 2, the red line is number of read/write operations with Red Hat based Kernel, the number of average read/write was 15,426 compare the measurement from the previous benchmark of average 4,033 read/write operations, this 382% improvement is a very one improvement (although the power of the server was better the previous one).
  • In Chart 2, the purple line shows the number of read/write operations with Oracle Unbreakable Kernel, it performed much better than the original kernel, Oracle UEK start from 32,110 and reach to the peak of 39,941 at 700 threads. On the contractually, Red Hat Based Kernel got 20,493 at the smallest number of threads and slipped down onward. Oracle UEK get 36,200 operations which is 234% improvement! And if we compare the measure from the previous benchmark, with technical stack from Oracle (hardware and OS kernel) we can enjoin near 9 times throughput.
  • The number of transaction shows in chart 3, it is consistent to the chart 1, UEK start from 1,690 transaction per second, creep to 2,102 at 700 threads, however Based Kernel start from 1,078 and slip down there after, the gap extended to 1,343 at 700 threads.


Chart 1. Read-only benchmark


Chart 2. Read-Write Benchmark

Chart 3. Read-write benchmark with transaction per second measurement

Conclusion
In the passed year, MySQL had lots of improvements, they enable MySQL to be the database that support mission critical applications. We hope the testing would help us figure out the right technical combination (from hardware, operating system to the database) for our customers. The result of this benchmark shows Oracle technical stack would offer superior performance for the user. With Oracle Linux we got near 300% performance improvement when the number of concurrent connection is 900, and compare with the result form previous benchmark, we got almost 9 times throughput, although the configuration of the hardware is better, it's still a significant improvement.

However I did not apply any performance analyze tool (for example sar) to collect the performance related information from the operating system layer, thus I have no idea what makes this huge difference between Red Hat based Kernel and Oracle UEK, hope I could have the opportunity to run the same benchmark with performance analyze tool.

2011年1月12日 星期三

MySQL5.5.8和5.0.77间运算效能的比较-简体中文版

前言
前一阵子和Oracle MySQL大中华区的业务负责人 – Sott Chen讨论制做一个MySQL DB appliance的可行性,希望能做出一套经过优化、即插即用(plug & play)的数据库设备(database appliance),这套设备在经过验证的情况下(例如,特定数量之下的同时联机数、数据量和SQL指令类型)可确保能达成一定的反应时间和吞吐量。这样的设备需要的技术应该有:
1.多核芯的X86硬件
2.经过调校的Linux或Unix操作系统
3.经过调校的MySQL数据库
为了验证这个想法的可行性,先从我最容易做的地方开始-证明经过调校的新版MySQL数据库的效能比一般Linux附带的MySQL社群版数据库效能更佳。

测试环境
1.基础设备,我请Oracle Linux部门的Hans Qing帮忙找到一台HP x86服务器,并在这台机装上Oracle Enterprise Linux,这台机器的配备如下:
CPU: 4x Intel(R) Xeon(R) CPU E5520 @ 2.27GHz, 16 Cores
Memory: 12GB
Hard Disk:300GB
OS: Oracle Enterprise Linux 5.5.8 x86_64

                                                   基本上这是一个压力测试,我的测试脚本是对一个有一亿行的table做读写兼具的OLTP作业。
我用Sysbench当作测试工具,Sysbench和MySQL都在同一台x86的PC Server上,所以网络的迟滞影响可降到最低。
Sysbench的指令如下:
1.nohup sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=100000000 --mysql-user=root --mysql-password=welcome1 --mysql-host=127.0.0.1 --mysql-port=3306 prepare
上述指令,Sysbench会在MySQL数据库建一个名为"sbtest" 的table,并且插入一亿行到该table中(详情请参阅Sysbench的手册 http://sysbench.sourceforge.net/docs/ ) ,第一个指令-nohup是要Linux在背景执行随后的sysbench指令,终端机可在执行sysbench时接受下一个的指令。
2.nohup sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=100000000 --num-threads= --mysql-user=root --mysql-password=welcome1 --mysql-host=127.0.0.1 --mysql-port=3306 run
上述指令是用Sysbench当成MySQL客戶端的程序对MySQL下达SQL指令,MySQL会将执行结果的报告存于nohup的记录档中-nohup.out,我们在执行上述指令时只需更动 的值就可仿真当并行联机数增加时MySQL之负荷状况及效能的变化

MySQL的调整和设定
由于Innodb为本测试所用的主要storage engine,我的调整主要针对innodb的相关参数做设定,MySQL 5.0.77的参数档(my.cnf)的内容如下:

max-connections=4000
innodb_buffer_pool_size=6G
key_buffer_size=512M
innodb_flush_method=O_DIRECT
innodb_file_per_table
innodb_log_buffer_size=4M

主要的调整有:
innodb_buffer_size设为6G,这台x86 PC Server有12G 的内存,因为Sysbench也用同一台机器,设得较为保守,如果整台机器只有MySQL在用应可设为总内存的75% (在这台机器上应为8G)。
innodb_flush_method设为O_DIRECT,少了重复的Buffer对DML会有一定的帮助。

MySQL 5.5.8的option file (my.cnf)调整如下:
max-connections=4000
innodb_buffer_pool_size=6G
key_buffer_size=512M
innodb_flush_method=O_DIRECT
innodb_file_per_table
innodb_log_buffer_size=4M
innodb_file_format=Barracuda
innodb_change_buffering=all
innodb_thread_concurrency=33
innodb_io_capacity=400
innodb_buffer_pool_instances=3
innodb_fast_shutdown=0
innodb_purge_threads=1

innodb_file_format设为新的格式-Barracuda,如此可完全发挥InnoDB 1.1的效能。
innodb_change_buffering设为all,在更改或删除数据时,若该table有非主键的index,可加速效能。
innodb_thread_concurrency设为33,为核芯数的两倍再加一。
innodb_io_capacity设为400,以增加在大量更新数据时flush dirty buffer到硬盘的效能。
innodb_buffer_pool_instances设为3,以增加同时做DML的容量。
innodb_fast_shutdown设为0,以开启多个rollback segment,增加DML的容量和效能。
innodb_purge_threads设为1,以在main thread之外再开一个purge thread,以改善5.1版以前main thread的忙碌程度。

测试结果
本测试由10个threads逐次增加到1020个threads(仿真1020个同时联机),其结果如下两图所示,蓝色线为经调校的MySQL 5.5.8的结果,橘线为经调校的MySQL 5.0.77的结果,黄线为未调校(完全用默认的参数) 的MySQL 5.0.77。图一为每秒交易量,图二为每秒的读写量。这两种吞吐量的衡量标准的结果基本上是一致的。经调校的5.5.8比经调校的5.0.77效能高7%至60%,5.5.8比未经调校的5.0.77效能高113%到11%。5.5.8最佳吞吐量出现在208个threads,5.0.77则出现在96个threads。
图一 - 每秒的交易量

另外,未经调校的MySQL 5.0.77的效能在threads数超过368时比经调校的MySQL 5.0.77高,可能的原因为InnoDB Buffer Pool在调校的MySQL设为6GB,而Sysbench的table (sbtest)一个row为250 Bytes,一亿个row为25GB,当SQL指令取用范围近乎均分散在整个table(Sysbench的测试特性),而且同时连线使用数多达一定数量时,MySQL会有大量的资料自磁碟载入,这所增加的负荷超会过InnoDB Buffer Pool所带来的记忆体缓存效益。



图二 - 每秒的读写量

进一步改善的可能性
由于时间的限制-这台x86 PC Server的借用期间只有一个月,同时在测时期间又参加在北京的Oracle OpenWorld 和大中华区的MySQL road show等杂事缠身,能用的时间实在不多,没有机会测操作系统层的调整对MySQL效能的影响。另外Table大小对效能的影响也没测到。
另外还有一些对效能有影响的MySQL参数在这次测试中也没用上,包括:
Innodb_commit_concurrency
InnoDB_log_file_size
InnoDB_flush_logs_at_trx_commit
InnoDB_file_io_threads
Innodb_max_dirty_pages_pct
row_format 设为compress
transaction isolation level的比较
等都值得一试,希望下次能有更寛裕的时间都能测到。

结论
新推出的MySQL5.5在效能、扩充性和可用度等各方面和以前的版本比起来均有长足的进步,尤其对最重要的储存引擎做了相当多的改良,使得MySQL更能发挥新进的硬件和操作系统在多个processor、大容量内存的优势,DBA们能用的工具也更多了,相对对的也使得MySQL的复杂度有些许的增加。本次的测试验证了MySQL的进步,和Oracle对MySQL用户的承诺。

MySQL5.5.8和5.0.77間運算效能的比較



前言
前一陣子和Oracle MySQL大中華區的業務負責人 – Sott Chen討論製做一個MySQL資庫設備(DB appliance)的可行性,希望能做出一套經過最佳化、即插即用(plug & play)的資料庫設備(database appliance),這套設備在經過驗證的情况下(例如,特定數量之下的同時連線數、資料量和SQL指令類型)可確保能達成一定的反應時間和吞吐量。這樣的設備需要的技術應該有:
1.多核芯的x86硬體
2.經過調校的Linux或Unix作業系統
3.經過調校的MySQL資料庫
為了驗證這個想法的可行性,先從我最容易做的地方開始-證明經過調校的新版MySQL資料庫的效能比一般Linux附帶的MySQL社群版資料庫效能更佳。

測試環境
1.基礎設備,我請Oracle Linux部門的Hans Qing幫忙找到一台HP x86伺服器,並在這台機裝上Oracle Enterprise Linux,這台機器的配備如下:
CPU: 4x Intel(R) Xeon(R) CPU E5520 @ 2.27GHz, 16 Cores
Memory: 12GB
Hard Disk:300GB
OS: Oracle Enterprise Linux 5.5.8 x86_64

測試方法
基本上這是一個壓力測試,我的測試據本是對一個有一億行的table做讀寫兼具的OLTP作業。
我用Sysbench當作測試工具,Sysbench和MySQL都在同一台x86的PC Server上,所以網路的遲滯影響可降到最低。
Sysbench的指令如下:
1.nohup sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=100000000 --mysql-user=root --mysql-password=welcome1 --mysql-host=127.0.0.1 --mysql-port=3306 prepare
上述指令,Sysbench會在MySQL資料庫建一個sbtest table,並且插入一億行到該table中(詳情請參閱Sysbench的手冊 http://sysbench.sourceforge.net/docs/ ) ,第一個指令-nohup是要Linux在背景執行隨後的sysbench指令,終端機可在執行sysbench時接受下一個的指令。
2.nohup sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=100000000 --num-threads= --mysql-user=root --mysql-password=welcome1 --mysql-host=127.0.0.1 --mysql-port=3306 run
上述指令是用Sysbench當成MySQL Client的程式對MySQL下達SQL指令,MySQL會將執行結果報的告存於nohup的記錄檔中-nohup.out,我們在執行上述指令時只需更動 的值就可模擬當併行連線數增加時MySQL之負荷狀況及效能的變化

MySQL的調整和設定
由於Innodb為本測試所用的主要storage engine,我的調整主要針對innodb的相關參數做設定,MySQL 5.0.77的參數檔(my.cnf)的內容如下:

max-connections=4000
innodb_buffer_pool_size=6G
key_buffer_size=512M
innodb_flush_method=O_DIRECT
innodb_file_per_table
innodb_log_buffer_size=4M

主要的調整有:
innodb_buffer_size設為6G,這台x86 PC Server有12G 的記憶體,因為Sysbench也用同一台機器,設得較為保守,如果整台機器只有MySQL在用應可設為總記憶體的75% (在這台機器上應為8G)。
innodb_flush_method設為O_DIRECT,少了重複的Buffer對DML會有一定的幫助。

MySQL 5.5.8的option file (my.cnf)調整如下:
max-connections=4000
innodb_buffer_pool_size=6G
key_buffer_size=512M
innodb_flush_method=O_DIRECT
innodb_file_per_table
innodb_log_buffer_size=4M
innodb_file_format=Barracuda
innodb_change_buffering=all
innodb_thread_concurrency=33
innodb_io_capacity=400
innodb_buffer_pool_instances=3
innodb_fast_shutdown=0
innodb_purge_threads=1

innodb_file_format設為新的格式-Barracuda,如此可完全發揮InnoDB 1.1的效能。
innodb_change_buffering設為all,在更改或刪除資料時,若該table有非主鍵的index,可加速效能。
innodb_thread_concurrency設為33,為核芯數的兩倍再加一。
innodb_io_capacity設為400,以增加在大量更新資料時flush dirty buffer到硬碟的效能。
innodb_buffer_pool_instances設為3,以增加同時做DML的容量。
innodb_fast_shutdown設為0,以開啟多個rollback segment,增加DML的容量和效能。
innodb_purge_threads設為1,以在main thread之外再開一個purge thread,以改善5.1版以前main thread的忙碌程度。

測試結果
本測試由10個threads逐次增加到1020個threads(模擬1020個同時連線),其結果如下兩圖所示,藍色線為經調校的MySQL 5.5.8的結果,橘線為經調校的MySQL 5.0.77的結果,黃線為未調校(完全用預設的參數) 的MySQL 5.0.77。圖一為每秒交易量,圖二為每秒的讀寫量。這兩種吞吐量的衡量標準的結果基本上是一致的。經調校的5.5.8比經調校的5.0.77效能高7%至60%,5.5.8比未經調校的5.0.77效能高113%到11%。5.5.8最佳吞吐量出現在208個threads,5.0.77則出現在96個threads。


圖一 - 每秒的交易量

另外,未經調校的MySQL 5.0.77的效能在threads數超過368時比經調校的MySQL 5.0.77高,可能的原因為InnoDB Buffer Pool在調校的MySQL設為6GB,而Sysbench的table(sbtest)一個row為250 Bytes,一億個row為25GB,當SQL指令取用範圍近乎均分散在整個table(Sysbench的測試特性),而且同時連線使用數多達一定數量時,MySQL會有大量的資料自磁碟載入,這個增加的負荷超會過InnoDB Buffer Pool所帶來的記憶體緩存效益。

圖二 - 每秒的讀寫量


進一步改善的可能性
由於時間的限制-這台x86 PC Server的借用期間只有一個月,同時在測時期間又參加在北京的Oracle OpenWorld 和大中華區的MySQL road show等雜事纏身,能用的時間實在不多,没有機會測作業系統層的調整對MySQL效能的影響,Table大小對效能的影響也没測到。
另外還有一些對效能有影響的MySQL參數在這次測試中也没用上,包括:
Innodb_commit_concurrency
InnoDB_log_file_size
InnoDB_flush_logs_at_trx_commit
InnoDB_file_io_threads
Innodb_max_dirty_pages_pct
row_format 設為compress
transaction isolation level的比較
等都值得一試,希望下次能有更寛裕的時間都能測到。

結論
新推出的MySQL5.5在效能、擴充性和可用度等各方面和以前的版本比起來均有長足的進步,尤其對最重要的儲存引擎做了相當多的改良,使得MySQL更能發揮新進的硬體和作業系統在多個processor、大容量記憶體的優勢,DBA們能用的工具也更多了,相對對的也使得MySQL的複雜度有些許的增加。本次的測試驗證了MySQL的進步,和Oracle對MySQL使用者的承諾。