Как я могу исследовать устойчивую высокую загрузку ЦП с помощью Microsoft.Exchange.Rpc.ClientAccess.Service.exe?

Один сервер CAS в нашем массиве использует почти 90% из четырех процессоров. Остальные серверы CAS находятся на 30%.

Как мне выяснить, что вызывает это увеличение?

Ниже представлен график:

Шесть (6) серверов CAS, обслуживающих 3000 пользователей в режиме RPC / HTTPS (Outlook в любом месте).
Windows 2008 R2
Недавно обновлен до Exchange 2010 SP1 RU6 (такое же поведение на RU3)
Каждый сервер CAS имеет четыре (4) виртуальных процессора.

Точки интереса

Поскольку мы попросили наших конечных пользователей настроить Activesync для другого URL-адреса, мы установили выделенный виртуальный IP-адрес на балансировщике нагрузки и изолировали два нижних сервера CAS. Сделать это было легко ... мы изменили публичную запись DNS, чтобы облегчить изоляцию. (Я бы хотел, чтобы лучшие практики MSFT поощряли использование изолированного URL-адреса для развертываний Activesync)
Высокий процессор в черном цвете исходит от ActiveSync.
Зеленый пик - от службы клиентского доступа RPC.

Я управлял MSFT DebugDiag на серверах и не знаю, правильный ли это инструмент для использования или что делать с некоторыми из более сложных результатов. Любые советы приветствуются.

Я обнаружил основную причину (ы) и обновлю их здесь:

Высокая загрузка ЦП CAS была вызвана

Серверы BES. Это было спорадическим и непостоянным
Ведение журнала. Наши процессы архивирования использовали 8000 MAPI-подключений к серверу и вызывали высокую загрузку ЦП.
Пользователи Outlook на NAT. Многие люди, использующие Outlook в любом месте, находились за NAT. Наш балансировщик нагрузки балансирует их по IP-адресу, а не по cookie (поскольку 2010 SP1 + поддерживает его)
Проблема с календарем Activesync. Айфоны забивали наш сервер обновлениями календаря, которые были отклонены из-за ошибки программирования Apple. Мы остановили пул приложений ActiveSync и обновили автообнаружение, чтобы направить всех пользователей Activesync на выделенный массив CAS.

В итоге решение заключалось в создании выделенного массива CAS для трафика Jornaling, Activesync и Outlook Anywhere. Мы разместили Journaling + BES на одном массиве. Это было плохое качество обслуживания и изоляция ошибок для каждой службы.

Инструмент, который мы использовали для определения виновника высокой загрузки ЦП, был «Exmon», но знайте, что запуск Exmon приведет к появлению файлов трассировки в \ program files (x86) \ Exmon. Если эти файлы не удалить, они могут заполнить диск.

Посмотрите, поможет ли это: http://social.technet.microsoft.com/Forums/nl/exchange2010/thread/55da7565-abc1-4c40-bade-7d3dc420de2e. Там обсуждается множество возможных причин.

У вас есть пользователи iPhone, iPad и т. Д.?
См. Ниже, если вы это сделаете.
Мы столкнулись с этим на работе.

http://www.networkworld.com/news/2013/021313-byod-ios-exchange-servers-266683.html Устройства iOS мешают серверам Exchange при синхронизации

(Ссылка в статье) http://support.microsoft.com/kb/2814847?wa=wsignin1.0 Быстрый рост журналов транзакций, использования ЦП и памяти в Exchange Server 2010, когда пользователь синхронизирует почтовый ящик с помощью устройства на базе iOS 6.1 или 6.1.1.

Обозреватель процессов может помочь понять, что именно делает процесс.

Однако учтите, что procxp.exe может использовать довольно много ресурсов процессора.