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