我有一台 HP Proliant BL68C G5 服务器，运行 Windows Server 2008 R2 标准版服务器，用作 Oracle 11g 数据服务器。
该机器本身具有 20gb RAM、双 Xeon 2.4ghz CPU、智能阵列 P400i 上的 146gb SAS 驱动器（Raid 1+0）作为操作驱动器以及用于 Oracle 文件的 HP Eva FC san 阵列。
我已经检查了 FC HBA 和 SAN 控制器的固件更新，确保 Windows 是最新的，并且我正在使用最新的 HP 驱动程序。
但是，Oracle 数据库的性能很慢，一位 Oracle 顾问查看了 Oracle 安装并认为是磁盘子系统存在问题。
在典型的繁忙会话期间运行 15 分钟后，我得到了以下数据。
磁盘时间百分比：平均：61 最大：15,145
平均磁盘读取队列长度：平均：1.043 最大：8.755
平均磁盘写入队列长度：平均：1.911 最大：756.456
% 处理器时间：平均：2.529 最大：23.655
平均磁盘秒/读取：平均：0.013 最大：0.041
平均磁盘秒/写入：平均：0.008 最大：0.153
内存可用字节数：平均：1.0780e+010 最大：1.0796e+010
据我所知，平均数字不错，但最大数字确实很高。我还知道，在使用 SAN 阵列时，磁盘时间不是最佳数字，但最大队列长度让我担心，它与 Oracle 所说的磁盘访问速度慢有关。
我查看了网络访问情况，在同一时间段内，流量吞吐量似乎最大为 75mbits，考虑到网络使用千兆以太网，这个数字似乎并不多。
有没有人遇到过类似的情况，或者对我如何进一步调查有任何指点。
对我来说，这台机器的性能似乎非常好，但是陷入与 Oracle 的争斗，以证明是他们的软件而不是 SAN 本身导致了磁盘问题，这令人非常沮丧。
我已尝试全面地描述，但如果有人有任何建议或需要更多信息，请随时询问。
答案1
平均磁盘秒/读取：平均：0.013 最大：0.041
平均磁盘秒/写入：平均：0.008 最大：0.153
我看到的唯一相关计数器。真的。队列 lentsh 有点难以判断。
对于高端 san，平均数和高数都太高了。看起来要么是 IO 瓶颈，要么是某处的配置问题。
对我来说，这台机器的性能似乎非常好，但是陷入与 Oracle 的争斗，以证明是他们的软件而不是 SAN 本身导致了磁盘问题，这令人非常沮丧。
主要是因为它是 SAN。它很慢。对于我拥有的中端 DAS 系统（Velociraptors，没有 SAS 磁盘），这些数字太高了，但对于真正的 SAN，它们真的真的真的很高。
但是最大队列长度令我担心，它与 Oracle 所说的磁盘访问速度慢有关。
现在，这是件棘手的事情。队列长度的解释取决于很多因素，说起来甚至都不是件有趣的事。756k 磁盘队列长度意味着 Oracle 在 SAN 上转储了大量内容，而 SAN 没有响应。显然，这表明存在瓶颈。但这些数字意味着什么？
另一方面，Sec/Write 从 0.008 秒变为 .153 秒。0.153 确实很慢。0.008 的启动速度并不算快（假设是真正的 SAN）。
绝对不是 Oracle 问题 - 您的磁盘子系统存在瓶颈。
答案2
由于这看起来像是一个 Windows 盒子，因此您可以从 Perfmon 中获得一些更好的指标。不要只使用平均队列长度，而是将其与“平均磁盘传输/秒”相结合。这两个指标应该可以让您更好地了解您似乎看到的存储瓶颈。如果队列长度在磁盘传输激增的同时激增，这非常清楚地表明您的 SAN 无法满足需求。
另一件需要关注的事情是随时间变化的性能。如果平均队列长度为 756 持续 4 秒，那么这只是一次爆发，其重要性不如每 15 秒左右达到该水平。
不管怎样，听起来你已经将存储推到了极限。