文章来源:http://niyunjiu.javaeye.com/blog/316471
Sysbench是一款流行的开源基准测试工具,用来测试不同操作系统平台即其上数据库的性能。由于我们目前讨论的是MySQL,我将重点讲解数据库测试部分。
Sysbench基准测试在测试OLTP时,先生成一张表,然后再运行一组查询命令。默认情况下,表中每一行数据约为250字节,并创建100行。根据我的经验,我 们创建1000万行。Allan有一篇关系测试细节的博客( http://blogs.sun.com/allanp/entry/tuning_mysql_on_linux)。
在此,我将从另外一个角度来介绍我们的测试。
使测试获得好得数据,这其实非常简单:
1 最大化CPU利用率
2 减少由于IO造成的延迟
最大化CPU利用率
提高资源利用率,对于获得最佳的测试性能非常重要。如果你拥有一台多核机器(现在很多机器都已经是多核),你需要并行执行多个线程,从而使系统中所有的核都得到利用。Sysbench通过--number-threads变量来确定内核数量。根据经验,通常当线程数接近或等于内核数量是,测试效果最佳。另外,你还需要提高在inno db内部执行的并发线程数量。从MySQL 5.0.19之后,innodb_thread_concurrency 参数的含义就改变了,因此请确定您设置了正确的值。我们发现,将该变量的值设置为0是最好的(无限线程)。
减少由于IO造成的延迟
消除IO延迟的一个方法是不要使用任何IO,例如,缓存所有的事情。Sysbench测试表中每一个行约为250字节,因此1000万行表中的数据量约为2.5GB 。大多数系统的内存都大于2.5GB,因此您可以将这个表都放入内存缓存中。
MySQL 使用变量innodb_buffer_size来确定缓存大小。如果您有足够的内存(在我们的测试中是2.5GB),您可以将整个表都放入缓存中。另一个策略(尤其是当您在使用32位MySQL时)是为innodb_buffer_size设一个较小的值,而在文件系统缓存中来缓存表。但是我认为在 innodb级别缓存数 据的效率更高。这将消除或明显减少所有的读。
对消除写而言,您可以选择进行只读测试,或使用一个可缓存(cache-enabled)的磁盘来写。缓存可以是NVRAM,也可以是磁盘上的写缓存。注意:使用没 有电池支持的缓存是非常危险的,请在您自己的磁盘上做缓存。
如果您仍然发现了由IO造成的延迟(转化为系统的空闲时间),您可以尝试添加更多线程来吸收可以的CPU。在寻找合适的平衡时,您需要格外小心。
Sysbench基准测试在测试OLTP时,先生成一张表,然后再运行一组查询命令。默认情况下,表中每一行数据约为250字节,并创建100行。根据我的经验,我 们创建1000万行。Allan有一篇关系测试细节的博客( http://blogs.sun.com/allanp/entry/tuning_mysql_on_linux)。
在此,我将从另外一个角度来介绍我们的测试。
使测试获得好得数据,这其实非常简单:
1 最大化CPU利用率
2 减少由于IO造成的延迟
最大化CPU利用率
提高资源利用率,对于获得最佳的测试性能非常重要。如果你拥有一台多核机器(现在很多机器都已经是多核),你需要并行执行多个线程,从而使系统中所有的核都得到利用。Sysbench通过--number-threads变量来确定内核数量。根据经验,通常当线程数接近或等于内核数量是,测试效果最佳。另外,你还需要提高在inno db内部执行的并发线程数量。从MySQL 5.0.19之后,innodb_thread_concurrency 参数的含义就改变了,因此请确定您设置了正确的值。我们发现,将该变量的值设置为0是最好的(无限线程)。
减少由于IO造成的延迟
消除IO延迟的一个方法是不要使用任何IO,例如,缓存所有的事情。Sysbench测试表中每一个行约为250字节,因此1000万行表中的数据量约为2.5GB 。大多数系统的内存都大于2.5GB,因此您可以将这个表都放入内存缓存中。
MySQL 使用变量innodb_buffer_size来确定缓存大小。如果您有足够的内存(在我们的测试中是2.5GB),您可以将整个表都放入缓存中。另一个策略(尤其是当您在使用32位MySQL时)是为innodb_buffer_size设一个较小的值,而在文件系统缓存中来缓存表。但是我认为在 innodb级别缓存数 据的效率更高。这将消除或明显减少所有的读。
对消除写而言,您可以选择进行只读测试,或使用一个可缓存(cache-enabled)的磁盘来写。缓存可以是NVRAM,也可以是磁盘上的写缓存。注意:使用没 有电池支持的缓存是非常危险的,请在您自己的磁盘上做缓存。
如果您仍然发现了由IO造成的延迟(转化为系统的空闲时间),您可以尝试添加更多线程来吸收可以的CPU。在寻找合适的平衡时,您需要格外小心。
安装:
- ./configure --with-mysql-includes=/opt/app/mysql/include/mysql --with-mysql-libs=/opt/app/mysql/lib/mysql
通过修改下面的参数,我们获得了最好的测试结果:
1 通过--num-threads 参数来使用多个sysbench线程
2 在my.cnf文件中设置innodb_thread_concurrency = 0
3 将innodb_buffer_size设置为大于或等于表大小
我在测试中,对my.cnf中的参数做了如下配置:
[mysqld]
datadir=/mysqldata
innodb_data_home_dir = /mysqldata
innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend
innodb_log_group_home_dir = /mysqldata
innodb_buffer_pool_size = 4096M(含有1000万行记录的表大小为2.5GB)
innodb_additional_mem_pool_size = 20M
innodb_log_file_size = 400M
innodb_log_buffer_size = 64M
innodb_thread_concurrency = 0
cpu测试
2、线程测试
3、磁盘IO性能测试
上述参数指定了最大创建16个线程,创建的文件总大小为3G,文件读写模式为随机读。
4、内存测试
上述参数指定了本次测试整个过程是在内存中传输 4G 的数据量,每个 block 大小为 8K。
5、OLTP测试
sysbench --num-threads=8 --max-requests=1000000 --test=oltp --mysql-table-engine=innodb --oltp-table-size=10000000 --mysql-socket=/tmp/mysql.sock --mysql-user=root --mysql-host=localhost --mysql-password=xxxx --mysql-db=sbtest run
上述参数指定了本次测试的表存储引擎类型为 myisam,这里需要注意的是,官方网站上的参数有一处有误,即 --mysql-table-engine,官方网站上写的是 --mysql-table-type,这个应该是没有及时更新导致的。另外,指定了表最大记录数为 1000000,其他参数就很好理解了,主要是指定登录方式。测试 OLTP 时,可以自己先创建
数据库
sbtest,或者自己用参数 --mysql-db 来指定其他
数据库
。--mysql-table-engine 还可以指定为 innodb 等 MySQL 支持的表存储引擎类型。
以下为本文DB的结果:
OLTP test statistics:
queries performed:
read: 140000
write: 50000
other: 20000
total: 210000
transactions: 10000 (1999.02 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 190000 (37981.47 per sec.)
other operations: 20000 (3998.05 per sec.)
Test execution summary:
total time: 5.0024s
total number of events: 10000
total time taken by event execution: 39.8898
per-request statistics:
min: 2.87ms
avg: 3.99ms
max: 43.48ms
approx. 95 percentile: 5.37ms
Threads fairness:
events (avg/stddev): 1250.0000/27.23
execution time (avg/stddev): 4.9862/0.00
queries performed:
read: 140000
write: 50000
other: 20000
total: 210000
transactions: 10000 (1999.02 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 190000 (37981.47 per sec.)
other operations: 20000 (3998.05 per sec.)
Test execution summary:
total time: 5.0024s
total number of events: 10000
total time taken by event execution: 39.8898
per-request statistics:
min: 2.87ms
avg: 3.99ms
max: 43.48ms
approx. 95 percentile: 5.37ms
Threads fairness:
events (avg/stddev): 1250.0000/27.23
execution time (avg/stddev): 4.9862/0.00
转载于:https://blog.51cto.com/cqfish/159606