MSMQ поврежден?

Я только начал с компанией, которая имеет собственное облачное решение. Они построили свой централизованный механизм очередей вокруг SQL Server. Во время разговора с техническим директором он говорит, что в прошлом они пробовали MSMQ, но столкнулись с проблемами, связанными с повреждением очередей большого объема. Я делал поиск в Интернете, но не могу найти ничего по этому вопросу.

Кто-нибудь слышал о такой вещи? Есть ли хорошие статьи по этому поводу?

Кроме того, они не используют WCF для этой цели. Решит ли транзакционный характер WCF эти проблемы коррупции?

2 ответа

Решение

Нет, MSMQ не поврежден.

Хью имеет в виду отображение памяти файлов хранения в виртуальную память и их фрагментация.

MSMQ работает в блоках по 4 МБ независимо от размера сообщения. Отправьте сообщение 5 КБ - получите блок 4 МБ. Отправьте еще одно сообщение размером 5 КБ - используйте тот же блок. В конце концов блок заполняется, и MSMQ начинает новый. Когда все сообщения в блоке будут прочитаны и использованы (в отличие от только что загляданного), файл будет удален. MSMQ ждет несколько часов перед удалением, на случай, если придет новое сообщение и ему нужен дом - нет смысла создавать новый файл, когда он висит пустым.

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

Если сообщение имеет переменный размер и не читается в формате FIFO, то могут начать появляться дыры. Например, сообщение размером 5 КБ читается, и приходит сообщение размером 4 КБ, оставляя 1 КБ свободного пространства. Со временем объем выделенной памяти будет отклоняться от фактического объема сообщений из-за накопленного мертвого пространства.

Это все нормально. Для MSMQ нет дефрагментации.

Заметки

  1. Диск пишет в чанках по 4кб
  2. Сообщения требуют непрерывного пространства
  3. Запись на диск

У меня был подобный опыт, хотя "испорченный" - не тот термин, который я бы использовал. "Фрагментированный" лучше. Мой опыт ограничен использованием транзакционных очередей, поэтому я не уверен, что вы можете избежать этой проблемы, используя нетранзакционные очереди.

При большой нагрузке служба msmq может проявлять утечку памяти, когда просто не освобождает память. Таким образом, вы можете получить msmq, работающий на все более и более высоких объемах рабочей памяти, что повлияет на производительность.

Я не очень понимаю причину, но это связано с тем, как MSMQ хранит сообщения на диске, и эти файлы хранения становятся фрагментированными.

То, что я это испытал, не обязательно означает, что вы тоже это сделаете, это может быть что-то особенное в том, как мы настроили msmq.

Обратите внимание, что это не то же самое, что фрагментация диска.

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

Что касается WCF, я предполагаю, что вы имеете в виду привязки msmq для WCF. Я использовал обе привязки, доступные для msmq, и не верю, что это изменит это поведение, так как это связано с базовой подсистемой msmq.

Другие вопросы по тегам