磁盘I/O的性能评估方法
通常,我们很容易观察到数据库服务器的内存和CPU压力。但是对I/O压力没有直观的判断方法。磁盘有两个重要的参数: Seek time、 Rotational latency。正常的I/O计数为:①1000/(Seek time+Rotational latency)*0.75,在此范围内属正常。当达到85%的I/O计数以上时则基本认为已经存在I/O瓶劲。理论情况下,磁盘的随机读计数为125、顺序读计数为225。对于数据文件而言是随机读写,日志文件是顺序读写。因此,数据文件建议存放于RAID5上,而日志文件存放于RAID10或RAID1中。
下面假设在有4块硬盘的RAID5中观察到的Physical Disk性能对象的部分值:
Avg. Disk Queue Length 12
Avg. Disk Sec/Read .035
Avg. Disk Sec/Write .045
Disk Reads/sec 320
Disk Writes/sec 100
Avg. Disk Queue Length,12/4=3,每块磁盘的平均队列建议不超过2。
Avg. Disk Sec/Read一般不要超过11~15ms。
Avg. Disk Sec/Write一般建议小于12ms。
从上面的结果,我们看到磁盘本身的I/O能力是满足我们的要求的,原因是因为有大量的请求才导致队列等待,这很可能是因为你的SQL语句导致大量的表扫描所致。在进行优化后,如果还是不能达到要求,下面的公式可以帮助你计算使用几块硬盘可以满足这样的并发要求:
Raid 0 -- I/Os per disk = (reads + writes) / number of disks
Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2
Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks
Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks
我们得到的结果是:(320+400)/4=180,这时你可以根据公式①来得到磁盘的正常I/O值。假设现在正常I/O计数为125,为了达到这个结果:720/125=5.76。就是说要用6块磁盘才能达到这样的要求。
但是上面的Disk Reads/sec和Disk Writes/sec是个很难正确估算的值。因此只能在系统比较忙时,大概估算一个平均值,作为计算公式的依据。另一个是你很难从客户那里得到Seek time、 Rotational latency参数的值,这也只能用理论值125进行计算。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· 周边上新:园子的第一款马克杯温暖上架
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· DeepSeek如何颠覆传统软件测试?测试工程师会被淘汰吗?
· 使用C#创建一个MCP客户端