Mysql数据库服务器性能配置优化二 — 文件系统及IO调度算法的选择
文件系统对于IO性能来说有着不小的影响，选择合适的文件系统可以最大化的发挥硬件能力，提高数据库性能。
Linux上常用的文件系统有ext3，xfs，jfs，reiserfs等。ext4，btrfs等牛x的新文系系统，由于还是太新了，我还不敢用到生产环境中。ext3和reiserfs之前看过一些测试资料，对于数据库应用性能都比较一般，这里就不测试了。
这里主要测试XFS和JFS的性能对比，版本如下：
db2:~/tpcc-mysql# mkfs.xfs -V
mkfs.xfs version 2.9.8
db2:~/tpcc-mysql# mkfs.jfs -V
mkfs.jfs version 1.1.14, 06-Apr-2009
其他的测试资料：
XFS, Reiser, JFS & ext3 performance on Suse 9 Enterprise
Mysql如何选择文件系统？（ext4 vs ext3 vs jfs vs xfs vs reiserfs性能比拼）
IO调度算法（IO Schedulers ）的选择也会对IO性能有不小的影响，不同的应用需要选用不同的IO调度算法，以达到最好的性能。怎么选择？在实际的应用环境中进行测试，比如是很多小文件的图片服务器或者大文件的下载服务器，与数据库使用的策略可能就是不一样的。
查看当前的IO调度：
db2:~# cat /sys/block/sdb/queue/scheduler
noop anticipatory [deadline] cfq
修改IO调度：
echo “deadline” > /sys/block/sdb/queue/scheduler
最好是确定选择后加到系统启动参数中，这样可以永久生效。
# vi /boot/grub/menu.lst
title Debian GNU/Linux, kernel 2.6.26-2-amd64
root (hd0,0)
kernel /boot/vmlinuz-2.6.26-2-amd64 root=/dev/sda1 ro quiet elevator=deadline
initrd /boot/initrd.img-2.6.26-2-amd64
Linux IO调度算法的详细说明请放狗找“linux IO Schedulers ”
一、Mysqlslap测试：
mysqlslap是mysql自带的一个测试工具，这里使用的是默认的my-huge.cnf，测试脚本如下：
#vi mysqlslap_benchmarks.sh
/opt/mysql/bin/mysqld_safe &
sleep 10
echo “————————-innodb test ———————–”
/opt/mysql/bin/mysqlslap -u root -h localhost -c 10,50,100,200,400 -i 2 –ENGINE=MyISAM –auto-generate-sql-load-type=mixed –number-of-queries=50000 –number-char-cols=5 –number
-int-cols=5 –auto-generate-sql
echo “————————-myisam test ———————–”
/opt/mysql/bin/mysqlslap -u root -h localhost -c 10,50,100,200,400 -i 2 –engine=myisam –auto-generate-sql-load-type=mixed –number-of-queries=50000 –number-char-cols=5 –number
-int-cols=5 –auto-generate-sql
killall mysqld
重点参数：
-c 10,50,100,200,400：表示同时的client数量，可以考察在不同并发下的情况
-i 2：运行几次测试，多次取平均值会更准确，当然更耗时。
–number-of-queries=50000：query次数
其他具体使用方法请Google，这里就不一一列举了。
| 测试项 | 10 client(单位s) |
50 client |
100 client |
200 client |
400 client |
| 默认my-huge.cnf, XFS(nobarrier), deadline, innodb |
134.1 |
95.4 |
97.0 |
129.5 |
151.3 |
| 默认my-huge.cnf, XFS(nobarrier), cfq, innodb |
141.8 |
95.6 |
96.1 |
122.6 |
185.7 |
| 默认my-huge.cnf, XFS, deadline, innodb |
141.5 |
95.7 |
97.8 |
128.4 |
193.8 |
| 默认my-huge.cnf, JFS, deadline, innodb |
135.7 |
95.7 |
95.9 |
117.9 |
157.6 |
| 默认my-huge.cnf, JFS, cfq, innodb |
128.9 |
95.3 |
96.1 |
136.3 |
192.2 |
| 默认my-huge.cnf, XFS(nobarrier), deadline, myisam |
129.0 |
134.9 |
137.9 |
168.7 |
195.4 |
| 默认my-huge.cnf, XFS(nobarrier), cfq, myisam |
126.5 |
135.7 |
137.8 |
164.2 |
167.2 |
| 默认my-huge.cnf, XFS, deadline, myisam |
129.5 |
132.9 |
138.4 |
169.9 |
222.5 |
| 默认my-huge.cnf, JFS, deadline, myisam |
124.0 |
92.9 |
95.3 |
103.1 |
145.4 |
| 默认my-huge.cnf, JFS, cfq, myisam |
134.8 |
96.6 |
93.3 |
129.0 |
146.8 |
mysqlslap测试结论：
1、XFS在mount的时候需要加上nobarrier参数以获得更好的性能。
2、innodb的表现，XFS和JFS差别不大，各有千秋。
3、myisam的表现，JFS明显比XFS好很多。
4、cfq在XFS下看数据并不比deadline慢，不同于网上的一些资料（http://www.mysqlperformanceblog.com/2008/12/18/xtradb-benchmarks-15x-gain/），在JFS下基本都慢于deadline。
http://www.mysqlperformanceblog.com/2010/05/25/flashcache-tpcc-workload/
有vadim牛人的这句话，还是用deadline吧。
Vadim
FractalizeR,
Sure it is not silver bullet, but in systems that allows many outstanding IO requests ( RAID10, SSD) CFQ just dies vs Deadline in OLTP workloads.
See for example http://www.mysqlperformanceblog.com/2009/01/30/linux-schedulers-in-tpcc-like-benchmark/
Also we have bunch of customers cases when performance problem was healed just by one command
echo deadline > /sys/block/sda/queue/scheduler
二、TPCC测试：
TPCC是perconatools的一部分，大牛Vadim Tkachenko 所出，他的很多文章也都是用这个工具才测试的。
工具地址：https://launchpad.net/perconatools
使用方法：
Apt-get install bzr
bzr branch lp:~percona-dev/perconatools/tpcc-mysql
db2:~# cd tpcc-mysql/src/
db2:~/tpcc-mysql/src# make all
这里有可能make不过，需要改一下Makefile里面mysql_config的路径。
尝试运行tpcc_load，可能会提示有某个lib找不到，可以把mysql/lib目录加到/etc/ld.so.conf.d/libc.conf中，运行一次ldconfig
建库（这里root密码设为123）：
/opt/mysql/bin/mysql -u root -p -h localhost tpcc < create_table.sql
/opt/mysql/bin/mysql -u root -p -h localhost tpcc < add_fkey_idx.sql
./tpcc_load localhost tpcc root 123 1
至此可以用tpcc_start进行测试了。
./tpcc_start localhost tpcc root 123 1 4 60 180
参考文章：
http://d.hatena.ne.jp/sh2/20090212 日文的，大概看的懂，没找到英文的。。。
测试用的mf.cnf:
[mysqld]
port = 3306
socket = /tmp/mysql.sock
datadir = /srv/mysql
skip-locking
key_buffer_size = 384M
max_allowed_packet = 1M
table_open_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
#query_cache_size = 32M
# Try number of CPU’s*2 for thread_concurrency
thread_concurrency = 16
default_table_type=MYISAM
innodb_buffer_pool_size=3G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_file_per_table=1
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=8M
innodb_log_files_in_group=2
innodb_log_file_size=128M
innodb_thread_concurrency=0
innodb_flush_method = O_DIRECT
innodb_write_io_threads=4
innodb_read_io_threads=4
innodb_io_capacity=800
innodb_adaptive_checkpoint=1
max_connections=3000
query_cache_size=0
skip-name-resolve
table_cache=2048
测试结果：
| 文件系统/IO调度 | deadline（TpmC） |
CFQ |
|
JFS |
22945.666 | 22477.334 |
| XFS(nobarrier) | 22424.334 | 21219.334 |
1、同样的文件系统下，deadline优于CFQ。
2、JFS在这个测试中优于XFS。
结论：
大多数的测试中，JFS优于XFS，所以数据库数据目录的文件系统使用JFS
在数据存放的盘使用deadline的IO调度算法。
