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调度算法。
查看完整版本： Mysql数据库服务器性能配置优化二 -- 文件系统及IO调度算法的选择
Tags: MySQL