在诊断由SQL Anywhere（9.0.2）运行的供应商软件的性能问题时，我偶然发现了一些关于I / O带宽的有趣数据。 根据9.0.2手册，数据库属性“CurrIO”显示“服务器发出但尚未完成的文件I / O的当前数量”。 但是，在给定硬件configuration和/或数据库利用率的情况下，该数字应该是什么还不清楚。
经过一番search之后，我发现SQL Anywhere 10.0.0手册在关于性能的章节中进一步详细介绍了这一设置：
要检测I / O带宽是否是限制因素，请检查CurrIO数据库统计信息。 如果此统计量不在图表中，请单击添加统计量button并selectCurrIO。 寻找这个统计数字的最大持续数字。 例如，在图上寻找高原; 它越宽，影响就越显着。 如果graphics的值等于或大于数据库服务器使用的物理磁盘数量的3 +，则可能表示磁盘系统无法跟上数据库服务器活动的级别。
这是说，例如，如果我在服务器中有5个磁盘，这个数字理想情况下应低于8？ 这个值的含义是否与10.0.0版本相同？ 我觉得难以置信的原因是下面这个命令的结果在我的具体情况中有点偏离：
SELECT db_property ( 'CurrIO' ), db_property ( 'MaxIO' ) 上述命令为CurrIO返回900以上，为MaxIO返回1150 。 我一直在监测这个数字几个小时，平均约为950 （感谢来自RisingRoad的Foxhound监视器）。 这些读数已经在正常的数据库负载下进行。
我的input/输出带宽是否真的不够好，还是我误解了这些数字？
这是当前的服务器configuration：
操作系统：Windows Server 2003 R2 32位
数据库版本：SQL Anywhere（Adaptive Server Anywhere）9.0.2.3381
CPU：4x Intel Xeon双核3.00GHz
RAM：26GB（22GB分配给SQL Anywherecaching）
HDD（C：/）：OS +临时文件位置
RAID 1
2x 36GB SCSI-320（15k RPM）
HDD（D：/）：DB文件位置
RAID 5
4个73GB SCSI-320（15k RPM）
HDD（E：/）：操作系统页面文件+日志文件位置（没有镜像日志）
RAID 5
4个73GB SCSI-320（15k RPM）
注意：RAID1和第一个RAID5（D：/）位于同一个RAID控制器上。 我们正计划在RAID10上升级RAID5和146GB（15k RPM）硬盘。 这种改变是否有助于我们明显的I / O带宽问题？
在处理RAID时，perfmon中的传统磁盘计数器可能会导致误导结果。 他们将显示cachingI / O而不是磁盘I / O。 因此，请确保您也查看% Idle Time计数器。 这可能是最准确的结果，但它会倒置（较低的百分比等于繁忙的磁盘）
在SA中，CurrIO统计不是SMP安全的。 你最好看一下Windows perfmon提供的“PhysicalDisk”计数器。 特别是：“当前磁盘队列长度”，“平均磁盘队列长度”，“平均磁盘写入队列长度”和“平均磁盘读取队列长度”。
我不确定“3 +＃磁盘”值来自哪里。 如果您期望在驱动器上执行大量的IO，那么在该驱动器上有几个未完成的IO是非常合理的。
查看数据库执行多lessI / O的另一种方法是查看caching统计信息。 如果数据库正在从caching中读取，则不会执行尽可能多的磁盘I / O操作。 可以查看的两个数据库属性是“CacheRead”和“CacheHits”，如下所示：
SELECT db_property ( 'CacheRead' ), db_property ( 'CacheHits' )
SQL Anywhere 10.0.0手册build议至less有70％的高速caching命中百分比。 如果低于此值，则可能需要为服务器分配更多caching。 你可以直接得到这个百分比：
SELECT STRING(((db_property ( 'CacheHits' ) / db_property ( 'CacheRead' )) * 100), '%')
在我的情况下，当数据库拥有22GB的caching时，命中率约为58％。 将caching设置为55GB后，命中率达到了97％。 尽pipe“CurrIO”和“MaxIO”属性的确切数字可能是不正确的，但是在这个变化之后，相对的下降也是非常剧烈的。