使用SQLIO评估数据库磁盘性能

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
简介:


对于DBA来说,安装SQLServer之前先要了解磁盘的性能,这个很重要。微软提供了SQLIO可以帮助我们在系统安装之前评估磁盘的性能。

 

1. 下载SQLIO并安装

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=20163

 

2.修改SQLIO’s 配置文件

 

如果直接启动SQLIO,它会使用8MB测试文件。由于现在存储的缓存都很大,所以不能真实的测试出性能,这里我将100的值修改为20GB。

打开param.Txt,修改100-20480(最后的100参数表上test文件的大小)

 

D:\testfile.dat 是要创建的测试文件名。如果你需要创建到其他磁盘,只需要修改这个值比如e:\testfile.dat.

 

3. 创建测试BAT测试脚本模拟不同的IO模式,保存为test.bat:(随机读写,8KB和64KB四种情况,你可以考虑用各种配置组合测试出磁盘的最佳性能).

 

sqlio -kW -t8 -s120 -o8 -frandom -b8 -BH-LS E:\TestFile.dat

sqlio -kR -t8 -s120 -o8 -frandom -b8 -BH-LS E:\TestFile.dat

sqlio -kW -t8 -s120 -o8 -fsequential -b64-BH -LS E:\TestFile.dat

sqlio -kR -t8 -s120 -o8 -fsequential -b64-BH -LS E:\TestFile.dat

 

参数含义:

 

· -kW and -kR: 测试读写

 

· -t8 and -o8: 使用8个线程模拟,因为SQLIO不受限于CPU的数量,所以你可以使用多于CPU数量。

 

· -s120: 测试持续 120seconds

 

· -b8 and -b64: 请求IO的大小 8KB/64KB。因为SQL Server随即IO基本都是8KB,但是如果读写数据多的话会多于8KB,所以这里用64KB模拟。

 

· -frandom and -fsequential: 代表了随即和顺序两种IO模式。 一般的SQL都是使用随即模式,但是备份LOG等使用顺序读写,所以模拟这两种情况。

 

4. 测试磁盘性能:

 

先做一个10秒钟的测试:

 

sqlio -kW -s10 -fsequential -t8 -o8 -b8 -LS-Fparam.txt timeout /T 10

 

上面的完成后执行第三步生成的test.bat

 

5.结果分析:

 

输出结果如下:

C:\Program Files (x86)\SQLIO>sqlio -kW -t8 -s120 -o8 -frandom -b8 -BH -LS -Fparam.txt
sqlio v1.5.SG
using system counter for latency timings, 3579545 counts per second
parameter file used: param.txt
 file e:\testfile.dat with 2 threads (0-1) using mask 0x0 (0)
2 threads writing for 120 secs to file e:\testfile.dat
 using 8KB random IOs
 enabling multiple I/Os per thread with 8 outstanding
 buffering set to use hardware disk cache (but not file cache)
using specified size: 20480 MB for file: e:\testfile.dat
initialization done
CUMULATIVE DATA:
throughput metrics:
IOs/sec:  1580.91
MBs/sec:    12.35
latency metrics:
Min_Latency(ms): 0
Avg_Latency(ms): 9
Max_Latency(ms): 2927
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  0 19 62 14  2  1  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  2

 

重要的部分已经用红线标出,IOs/sec相当于磁盘的IOPs,MB/s磁盘数据的吞吐量。 底部的可以忽略,这些值表示了磁盘的反应时间。

 

另外针对于SQLIO的输出结果有一个非常好用的分析工具(SQLIO Analyzer),将SQLIO的结果保存到txt文件,但后导入分析工具,可以出现下面的图表结果(方便吧)。

 

下载:http://tools.davidklee.net/sqlio.aspx

 

更多内容可以参考:

 

Benchmarking SQL Server IO with SQLIO http://www.mssqltips.com/sqlservertip/2127/benchmarking-sql-server-io-with-sqlio/

SQLIO Tutorial:http://sqlserverpedia.com/blog/sql-server-performance-tuning/sqlio-tutorial/

相关文章
|
2月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
103 3
|
6月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
2月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(上)
最终建议:当前系统是完美的读密集型负载模型,优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存,预期可降低30%的CPU负载,同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
185 6
|
2月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(中)
使用MYSQL Report分析数据库性能
124 1
|
3月前
|
缓存 关系型数据库 MySQL
MySQL数据库性能调优:实用技术与策略
通过秉持以上的策略实施具体的优化措施,可以确保MySQL数据库的高效稳定运行。务必结合具体情况,动态调整优化策略,才能充分发挥数据库的性能潜力。
169 0
|
12月前
|
XML Java 数据库连接
性能提升秘籍:如何高效使用Java连接池管理数据库连接
在Java应用中,数据库连接管理至关重要。随着访问量增加,频繁创建和关闭连接会影响性能。为此,Java连接池技术应运而生,如HikariCP。本文通过代码示例介绍如何引入HikariCP依赖、配置连接池参数及使用连接池高效管理数据库连接,提升系统性能。
214 5
|
8月前
|
SQL 关系型数据库 MySQL
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
|
8月前
|
物联网 测试技术 API
时序数据库 InfluxDB 3.0 版本性能实测报告:写入吞吐量提升效果验证
TSBS 测试表明,对于少于 100 万台设备的数据集,InfluxDB OSS 3.0 的数据写入速度实际上比 InfluxDB OSS 1.8 更慢。 对于 100 万台及以上设备的数据集,InfluxDB OSS 3.0 的数据写入性能才开始超过 InfluxDB OSS 1.8。 InfluxDB OSS 3.0 的数据写入接口与 InfluxDB 1.8 并不兼容,用户无法顺利迁移。
621 7
|
9月前
|
数据库
【YashanDB 知识库】误配置 SYSTEM 级别的 STATISTICS_LEVEL 参数为 ALL 导致数据库性能下降
**标题:误配置 SYSTEM 级别的 STATISTICS_LEVEL 参数为 ALL 导致数据库性能下降** **简介:** 数据库性能骤降至正常水平的百分之一,主要表现为大量 free buffer wait 等待事件。原因是系统级别 STATISTICS_LEVEL 被误设为 ALL。解决方法是将其恢复为默认值 TYPICAL,执行命令:`ALTER SYSTEM SET statistics_level='TYPICAL' SCOPE=BOTH;` 以恢复正常性能。

热门文章

最新文章