如何通过 Microsoft.Exchange.Rpc.ClientAccess.Service.exe 调查持续的高 CPU 使用率？

Question

我们阵列中的一台 CAS 服务器使用了其 4 个 CPU 中的近 90%。其余的 CAS 服务器占 30%。

我应该如何调查导致这种增加的原因？

下图为：

• 六 (6) 台 CAS 服务器以 RPC/HTTPS（Outlook 随处可见）模式为 3,000 名用户提供服务。
• 视窗 2008 R2
• 最近升级到 Exchange 2010 SP1 RU6（RU3 上的行为相同）
• 每个 CAS 服务器有四 (4) 个虚拟 CPU

兴趣点

• 由于我们要求最终用户针对不同的 URL 配置 Activesync，因此我们在负载均衡器上设置了专用 VIP，并隔离了底部的两个 CAS 服务器。这样做很容易……我们更改了公共 DNS 条目以促进隔离。（我希望 MSFT 最佳实践鼓励 Activesync 部署的独立 URL）
• 黑色的高 CPU 来自 ActiveSync。
• 绿色尖峰来自 RPC 客户端访问服务。

我在服务器上运行了 MSFT 的DebugDiag，但不知道这是否是正确的工具，或者如何处理一些更高级的结果。任何提示表示赞赏。

Answer 1

我已经发现了根本原因并将在此处更新：

CAS CPU 过高的原因是

• BES 服务器。这是零星且多变的

• 写日记。我们的归档进程使用了​​ 8000 个与服务器的 MAPI 连接，导致 CPU 占用过高

• NAT 上的 Outlook 用户。许多在任何地方使用 Outlook 的人都位于 NAT 后面。我们的负载均衡器通过 IP 而不是 cookie 对它们进行负载均衡（因为 2010 sp1+ 支持它）

• Activesync 日历问题。iPhone 正在向我们的服务器发送日历更新，但由于 Apple 编程错误而被拒绝。我们停止了 ActiveSync 应用程序池并更新了自动发现，将所有 Activesync 用户指向专用的 CAS 阵列

因此，最终的解决方案是为 Jornaling、Activesync 和 Outlook Anywhere 流量创建专用 CAS 阵列。我们将 Journaling + BES 放在同一阵列上。对于每项服务来说，这都是一个糟糕的 QOS 和故障隔离。

我们用来识别高 CPU 罪魁祸首的工具是“Exmon”，但只需知道运行 Exmon 会导致跟踪文件出现在 \program files(x86)\Exmon 中。如果不删除这些文件，它们可能会填满驱动器。