处理多瓶颈问题

上一次修改主题： 2005-05-18

服务器遇到多瓶颈是一种普遍现象。但是，了解是否发生了任何因果关系非常重要 － 即其中一个子系统的性能问题影响了其他子系统。例如，受 CPU 限制的服务器积压队列，进而导致对 SMTP 磁盘的异常过度使用。

由于子系统之间可能会发生因果关系，所以应分析与以下内容有关的性能日志：

• 分配给服务器的角色。
• 引发一个或多个子系统性能下降的原因。

通常，应当缓解每处瓶颈，然后查看排除问题的这部分故障后的效果。此外，强制实施策略可能也足以缓解由多瓶颈引发的问题。例如，强制实施 POP3 检索的邮件大小可以减少数据库磁盘的负载。但是，强制措施可能还不够。在许多情况下，需要升级或重新设计硬件。

多瓶颈示例

在本示例中，Exchange 服务器是承载 6,000 个用户的邮箱服务器。它与三个直接附加存储数组相连：

• 一个数组有数据库。
• 另一个数组有事务日志。
• 第三个数组有 SMTP 磁盘。

此 Exchange 服务器有两个存储组，每个存储组带有两个专用数据库，每个数据库有 1,500 个用户。用于备份和恢复的 SLA 将存储组的数量限制为两个。

出现的问题是，当用户在日间以联机模式使用 Microsoft® Office Outlook® 时，响应速度很慢。

查看症状

通过收集本服务器性能降低的日间八小时使用期内的性能记录，可以明显看出 MSExchangeIS\RPC Requests 计数器的值一直保持在 60 左右，并且对某些客户所请求的操作的响应速度较慢。此外，MSExchangeIS\RPC Averaged Latency 计数器不断达到或超过 100 毫秒。这些都是需要分离的性能问题的明显症状。

对此性能日志的分析揭示了数据库驱动器、日志驱动器以及 CPU 的性能问题。下列部分将说明应使用那些性能计数器来确定各个问题。

问题 1 － 数据库驱动器性能差

Exchange 服务器与无法处理 I/O 负载的存储区域网络相连接。如图 10 所示，数据库驱动器的写入延迟（如 PhysicalDisk\Average Disk sec/Write 计数器所示）平均为 62 毫秒，具有频繁超过 80 毫秒的峰值，其中一些甚至超过了 100 毫秒。

问题 1 的解决方案

通过添加其他数组和控制器，然后将存储组拆分为独立数组，可以改进数据库驱动器的性能。

问题 2 － 日志驱动器性能差

如下图所示，低速的事务日志驱动器导致 Database\Log Record Stalls/sec 计数器的平均值为 114 次停顿/秒，其峰值不断超过 150 次停顿/秒。此外，从 Database\Log Record Stalls/sec 计数器具有多个超过 20 的峰值可以看出，还有日志线程等待频繁出现。

问题 2 的解决方案

负责事务日志的控制器遇到了问题。控制器禁用了回写缓存功能。使用回写缓存功能可正常运作的新控制器替换旧控制器后，可解决停顿问题。

问题 3 － CPU 限制

如下图所示，服务器遇到很高的 CPU 使用率（Processor\% Processor Time 计数器的平均值为 97%）和大型处理器队列（如 System\Processor Queue Length 计数器所示）。

问题 3 的解决方案

数据库和事务日志处的延缓加剧了对 CPU 的使用，导致上下文切换的次数多于实际需求（此性能日志上的平均值为 50,000），从而过度使用 CPU。通过解决问题 1 中的数据库问题和问题 2 中的事务日志问题，即可解决该图中所示的 CPU 使用率问题。