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

本文链接：https://blog.csdn.net/zjmzs/article/details/6068432

文件系统对于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