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=innodb --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数据库服务器性能配置优化一 -- 硬件配置及优化，RAID优化

Mysql数据库服务器性能配置优化二 -- 文件系统及IO调度算法的选择

Mysql数据库服务器性能配置优化三 -- Mysql编译配置优化，XtraDB使用，my.cnf优化