我一直在监控OLTP数据库的性能(约150GB);平均磁盘秒/读取和平均磁盘秒/写入值在24小时内超过20毫秒。
我需要明确解释为什么业务应用程序对这些计数器上的“不太好”的性能没有影响。我还需要施加一些压力让存储用户重新检查他们的配置,因为它适用于在SAN上放置mdf,ldf和tempdb文件。目前,我的论点不稳定,但我对那些不了解IOP和磁盘延迟之间差异的人表达了我的观点。
除了物理硬件的限制以及跨物理磁盘放置数据文件之外,还有什么会影响这些计数器值吗?例如:每秒的事务数,查询的大小,写得不好的查询或缺少索引?我的读数说“不”,但在这次辩论中我需要一个权威的声音。
答案 0 :(得分:1)
有很多因素会影响整体延迟。要真正将其统治为SAN,您需要查看您提到的“平均磁盘秒/读取计数器”和“平均桌面秒/写入计数器”。只需确保您正在查看“物理磁盘”对象,而不是“逻辑磁盘”对象。逻辑磁盘计数器包括文件系统开销,可能会有所不同,具体取决于不同的因素。
获得物理磁盘的计数器后,您需要将它们与服务器所连接的存储单元的延迟计数器进行比较。你提到“存储民谣”所以我会假设这是一个不同的团队,希望他们会很好并为你提供信息。
如果是存储单元问题,那么这两个计数器应该匹配得非常好。这表明存储单元真正运行缓慢。如果存储单元计数器显示更好,那么它介于两者之间。根据您使用的存储网络类型,这将是将服务器和存储连接在一起的HBA / NIC /交换机。或者,如果它是一个虚拟机,那么主机统计数据也将证明是有用的。
答案 1 :(得分:0)
除了明显的原因,例如“缓冲池内存不足”,延迟主要取决于存储的实际实现方式。
如果您的服务器有外部SAN,通常问题在于它可能会为您提供出色的吞吐量,但它永远不会(再次,通常)为您提供出色的延迟。这就是事情的方式。对于重负载的OLTP系统来说,这可能会成为一个真正令人头疼的问题,当然。
因此,如果您要从存储中挤出最后一微秒,很可能您需要本地驱动器。那,你的RAID 10应该有足够的主轴来应对负载。