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

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

(Все это виртуальная машина под vSphere 4.0 Update 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 веб-серверов находятся в одной виртуальной локальной сети, а серверы Cluster и серверы приложений - во второй виртуальной локальной сети. Между виртуальными локальными сетями нет брандмауэров.

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

performance msmq

— mrdenny
источник

Оказывается, причиной медленного чтения MSMQ была проблема приложения. Службы, которые читают из очереди, затем отправляются в общую папку. Общий файловый ресурс начал занимать все больше и больше времени, из-за чего службы работали медленнее, что приводило к резервному копированию очередей, и теперь у нас беспорядок. Очевидно, наша пользовательская база выросла намного быстрее, чем планировалось, и мы используем одну из групп RAID в сети SAN, в которой размещены общие файловые ресурсы. В понедельник мы поставим срочный заказ на большее пространство SAN с нашим поставщиком.

— Мрденни

Мы не увидели роста этой очереди раньше времени, потому что наш сервер мониторинга - это сервер Windows 2003, а машина с Windows 2003 не может удаленно отслеживать кластерные очереди MSMQ для Windows 2008. Мониторинг сервера уже запланирован на обновление в марте. <вздох>

— Мрденни

Ответы:

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

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

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

Приветствия Джона Бруквелла (MSFT)

В этот момент мне позвонили в PSS, и я жду, когда они перезвонят мне. Я остановил поступление сообщений в очередь на веб-серверах. На этом этапе все исходящие очереди на веб-серверах заполнены 1 гигабайтом информации. Всего в кластеризованных очередях около 4,5 миллионов сообщений. Обычно мы храним очень мало сообщений в очередях, так как данные обрабатываются очень быстро. Что-то случилось (не уверен что) и все пошло к черту.

— Мрденни

Джон, спасибо, что заглянул за меня. Судя по выводу tmq, я думаю, это моя проблема. Ограничения для пулов (рассчитывается приблизительно в килобайтах). Постранично: предел 307,200 используется для 397% Nonpaged: предел 262,144 используется для 49% Если вы находитесь в Редмонде во время саммита MVP, дайте мне знать, пиво на мне.

— Мрденни

@ user34024 мы нашли первоначальную проблему, которую я поставил в комментарии выше. Спасибо за помощь.

— Мрденни

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

HTH, Чак.

— SQLGuyChuck
источник

Смогли ли они определить, что именно вызвало замедление, когда более 4 веб-серверов общаются с одним сервером MSMQ? Хранилище - это прямое хранилище SAN через iSCSI, поэтому не должно быть проблем с хранилищем. Я попробую выключить 4 из 8 веб-серверов и посмотрю, что у меня получится. Если я скажу своему боссу купить новое оборудование, мне понадобится чертовски веская причина.

— Мрденни

Просто болтливость сообщений. Они также нашли некоторые конфигурации пропуска аутентификации.

— SQLGuyChuck

Я предполагаю, что я скачаю wireshark и положу его на сервер MSMQ и посмотрю, что он показывает. Не могу поставить его на веб-серверы, он падает примерно через 30 секунд из-за нагрузки сетевого трафика.

— Мрденни

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

— Мрденни

мы нашли первоначальную проблему, которую я поставил в комментарии выше. Спасибо за помощь.

— Мрденни

Ссылаясь на ваш комментарий об отсутствии удаленного администрирования, да, это не очень хорошая история с 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)