处理多瓶颈问题

 

上一次修改主题: 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 毫秒。这些都是需要分离的性能问题的明显症状。

549586e7-902c-464f-9546-482e25523259

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

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

5c813b6b-11d0-4de5-8d16-764d56d7a473

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

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

c1f0b097-09db-45db-8e26-f18d8be4b30d

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

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

c64c132f-c483-4c42-944e-9edfdcf3179c

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

 
显示: