在诊断运行在 SQL Anywhere (9.0.2) 上的供应商软件的性能问题时，我偶然发现了一些有关 I/O 带宽的有趣数据。根据 9.0.2 手册，数据库属性“CurrIO”显示“服务器发出但尚未完成的当前文件 I/O 数量”。但是，考虑到硬件配置和/或数据库利用率，尚不清楚这个数字应该是多少。
经过一番搜索，我发现 SQL Anywhere 10.0.0 手册在其有关性能的章节中更详细地介绍了此设置：
要检测 I/O 带宽是否是限制因素，请检查 CurrIO 数据库统计信息。如果图表上没有此统计信息，请单击添加统计信息按钮并选择 CurrIO。查找此统计信息的最大持续数字。例如，查找图表上的高平台；它越宽，影响就越大。如果图表的持续值等于或大于 3 + 数据库服务器使用的物理磁盘数量，则可能表明磁盘系统无法跟上数据库服务器活动的水平。
这是否意味着，例如，如果我的服务器中有 5 个磁盘，那么这个数字理想情况下应该低于 8？这个值的含义对于版本 9.0.2 和 10.0.0 是否相同？我之所以觉得难以置信，是因为以下命令的结果在我的特定情况下有点不对劲：
SELECT db_property ( 'CurrIO' ), db_property ( 'MaxIO' )
上述命令返回900对于 CurrIO 和1150对于 MaxIO。我已经监控这个数字几个小时了，平均值大约是950（感谢 RisingRoad 的 Foxhound 监控器）。这些读数是在正常数据库负载下获取的。
我的 I/O 带宽是否真的像看上去的那样不足，还是我误解了这些数字？
这是当前的服务器配置：
操作系统：Windows Server 2003 R2 32位
数据库版本：SQL Anywhere（Adaptive Server Anywhere）9.0.2.3381
CPU：4x Intel Xeon 双核 3.00GHz
RAM：26GB（其中 22GB 分配给 SQL Anywhere 缓存）
HDD（C:/）：操作系统 + 临时文件位置
RAID 1
2x 36GB SCSI-320（15k RPM）
HDD（D:/）：数据库文件位置
RAID 5
4x 73GB SCSI-320（15k RPM）
HDD（E:/）：OS 页面文件 + 日志文件位置（没有镜像日志）
RAID 5
4x 73GB SCSI-320（15k RPM）
注意：RAID1 和第一个 RAID5 (D:/) 位于同一个 RAID 控制器上。我们计划使用 RAID10 中的 146GB (15k RPM) 驱动器升级两个 RAID5。这种改变是否有助于解决我们明显的 I/O 带宽问题？
答案1
处理 RAID 时，perfmon 中的传统磁盘计数器可能会返回误导性结果。它们将显示缓存 I/O，而不是磁盘 I/O。因此，请确保您也查看了计数器% Idle Time。这可能是最准确的结果，但它会被反转（百分比越低，磁盘越忙）
答案2
CurrIO 统计信息在 SA 中不是 SMP 安全的。您最好查看 Windows perfmon 提供的“PhysicalDisk”计数器。特别是：“当前磁盘队列长度”、“平均磁盘队列长度”、“平均磁盘写入队列长度”和“平均磁盘读取队列长度”。
我不确定“3+#disks”这个值从何而来。如果您预计驱动器上会执行大量 IO，那么该驱动器上有几个未完成的 IO 是非常合理的。
答案3
另一种查看数据库执行了多少 I/O 的方法是查看缓存统计信息。如果数据库正在从缓存中读取，则它不会执行太多的磁盘 I/O。可以查看的两个数据库属性是“CacheRead”和“CacheHits”，如下所示：
SELECT db_property ( 'CacheRead' ), db_property ( 'CacheHits' )
SQL Anywhere 10.0.0 手册建议缓存命中率至少为 70%。如果低于该值，则可能需要为服务器分配更多缓存。您可以像这样直接获取该百分比：
SELECT STRING(((db_property ( 'CacheHits' ) / db_property ( 'CacheRead' )) * 100), '%')
在我的特定情况下，当数据库具有 22GB 缓存时，命中率约为 58%。将缓存设置为 55GB 后，命中率上升到 97%。虽然“CurrIO”和“MaxIO”属性的确切数字可能不正确，但在此更改之后，相对下降幅度也很大。