Назад | Перейти на главную страницу

MSMQ очень медленно принимает сообщения

У нас есть довольно большая установка среды MSMQ, которую сегодня решили прекратить.

(Все является виртуальной машиной в vSphere 4.0 с обновлением 1)

Есть 8 веб-серверов, которые получают данные от клиентов в сети. На всех этих машинах установлен MSMQ, и они просто отправляют сообщение MSMQ на главный сервер MSMQ. В настоящее время сообщения накапливаются в очереди исходящих сообщений. Это машины Windows 2008 Web Edition с 2 ГБ ОЗУ и 2 виртуальными ЦП.

У нас есть кластерный сервер MSMQ (Windows Cluster Server), который получает сообщения от 8 веб-серверов. Нет ограничений на количество данных, которые могут находиться в очередях. На жестком диске 50 Гб, а свободного места 46 Гб. Это машины под управлением Windows 2008 Enterprise Edition с 8 ГБ ОЗУ и 4 виртуальными ЦП. Раньше в кластере было 2 виртуальных ЦП, но загрузка ЦП достигала 100%, поэтому я увеличил оба узла кластера Windows до 4 виртуальных ЦП.

Есть 4 сервера приложений, которые читают сообщения из очередей и обрабатывают их.

Обычно все это работает отлично, но не сегодня.

Сегодня утром все идет очень медленно. 8 веб-серверов в настоящее время показывают до 300 тыс. Сообщений, находящихся в исходящих очередях. Кластерный сервер в настоящее время показывает в очередях более миллиона сообщений (некоторые из них не превышают 200 КБ).

Если я посмотрю на perfmon на 8 веб-серверах, он покажет, что в среднем я отправляю 2 сообщения в секунду. Если я посмотрю на perfmon в кластере, он показывает, что в кластер поступает ~ 7 сообщений в секунду.

Машины, выполняющие чтение, не получают много сообщений каждая. Самые быстрые сервисы получают 10-12 сообщений в секунду, самые медленные показывают 0 или 1.

Единственное изменение за последнее время - это то, что мы изменили количество интерфейсных веб-серверов с 4 на 8. Мы сделали это около 2 недель назад без проблем. Во вторник мы выключили их, чтобы посмотреть, как остальные 4 справятся с нагрузкой. В среду мы снова включили четыре новые машины.

Диск в кластере показывает очень низкий уровень ввода-вывода и отсутствие очереди.

На всякий случай я обновил PowerPath до последней версии, но это никому не помогло.

8 веб-серверов находятся в одной vLAN, а серверы Cluster'd и серверы приложений находятся во второй vLAN. Между виртуальными локальными сетями нет межсетевых экранов.

И нет ничего полезного в журналах приложений или системных журналах ни на одной из машин.

Каждый раз, когда кто-то говорит, что у него более миллиона сообщений, срабатывают клаксоны тревоги! Сообщения требуют управления памятью ядра (выгружаемого пула). Если у вас такое огромное количество сообщений, возможно, вы исчерпываете все, что доступно на кластерном сервере. Оптимальное количество сообщений в очереди равно нулю - в основном убедитесь, что вы обычно можете обрабатывать сообщения быстрее, чем они могут прибыть.

Я бы рекомендовал выключить веб-серверы и полностью обработать накопившиеся сообщения, прежде чем снова вернуть их в онлайн.

Ссылка на пункт 4 этого сообщения в блоге: http://blogs.msdn.com/johnbreakwell/archive/2006/09/18/insufficient-resources-run-away-run-away.aspx

Ура, Джон Брейквелл (MSFT)

Я спросил одного из наших системных администраторов, и он сказал, что наша волшебная точка заключалась в том, что 4 веб-сервера максимально попадали в ящик MSMQ на виртуальных машинах, а затем они перешли на аппаратный ящик для решения. Также попробуйте захват пакетов, чтобы узнать, что происходит. Многое ли в аутентификации идет в AD? Поскольку MSMQ болтлив, вам нужно ограничить сетевые пути и, возможно, путь аутентификации.

HTH, Чак.

Ссылаясь на ваш комментарий об отсутствии удаленного администрирования, да, это не лучшая история с MSMQ и счетчиками производительности. Для тех, кто следит за темой и хочет знать, какие комбинации операционных систем работают, загляните в блог Motley Queue:

Счетчики производительности MSMQ 4.0 и ключ реестра NetNameForPerfCounters http://blogs.msdn.com/motleyqueue/archive/2007/12/14/msmq-4-0-performance-counters-and-the-netnameforperfcounters-registry-key.aspx

Ура, Джон Брейквелл (MSFT)