файловая система хранилища очередей заполнена в websphere mq

WMQ не сжимает файлы очереди в режиме реального времени. Например, у вас есть 100 сообщений в очереди, и вы потребляете первое из них. WMQ не сжимает файл и не перемещает все сообщения на одну позицию вверх. Если бы он пытался сделать это для каждого сообщения, вы никогда не смогли бы получить пропускную способность, которую вы сейчас видите в продукте.

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

Событие, которое вы описываете, теоретически может произойти при некоторых очень специфических условиях, однако оно будет крайне редким. На самом деле за 15 лет работы с WMQ я видел только пару случаев, когда задержка при сжатии файла очереди была даже заметной. Я предполагаю, что на самом деле здесь происходит то, что одно из ваших предположений или наблюдений ошибочно. Например:

Действительно ли очередь была пуста?

• Очередь определенно была пустой после того, как вы удалили файл. Откуда вы знаете, что он был пуст до того, как вы удалили файл?
• Если в какой-либо очереди были непостоянные сообщения, очередь будет пустой после перезапуска QMgr. Это еще один случай, когда очередь может казаться пустой после перезапуска QMgr, но не во время сбоя.
• Если сообщение извлекается из очереди в точке синхронизации, глубина очереди уменьшается, но сообщение остается активным в файле очереди. Если очередь очищается за одну транзакцию, она сохраняет свою полную глубину до тех пор, пока не произойдет COMMIT. Это может создать впечатление, что очередь пуста, когда это не так.

Действительно ли файл очереди заполнил файловую систему?

• Экстенты журнала могут заполнять файловую систему даже при использовании циклических журналов. Например, при большом значении для вторичных экстентов файлы журналов могут значительно увеличиваться, а затем так же быстро исчезать.
• Файлы FDC могут заполнять файловую систему, в зависимости от того, как они были распределены.

Был ли это вообще MQ?

• Если QMgr разделяет пространство файловой системы с другими пользователями или приложениями, временные файлы могут заполнить пространство.

Одна из проблем, с которой мы сталкиваемся очень часто, заключается в том, что приложение пытается поместить в очередь более 5000 сообщений и получает ошибку QFULL. Самое первое, что делает большинство людей, это устанавливает MAXDEPTH(999999999), чтобы убедиться, что это НИКОГДА не повторится. Проблема в том, что QFULL — это мягкая ошибка, от которой приложение может восстановиться, но заполнение файловой системы — это серьезная ошибка, которая может вывести из строя весь QMgr. Установка MAXDEPTH(999999999) заменяет управляемую мягкую ошибку фатальной ошибкой. Администратор MQ несет ответственность за то, чтобы MAXDEPTH и MAXMSGL в очередях были установлены таким образом, чтобы базовая файловая система не заполнялась. В большинстве магазинов осуществляется дополнительный мониторинг всех файловых систем, чтобы выдавать предупреждения задолго до их заполнения.

Подводя итог, можно сказать, что WMQ в большинстве случаев очень хорошо справляется с сокращением файлов очереди. В частности, когда очередь опустошается, это естественная точка синхронизации, в которой файл может быть сжат, и это обычно происходит в течение нескольких секунд после опустошения очереди. Вы либо столкнулись с редким состоянием гонки, при котором файл не был сжат достаточно быстро, либо здесь происходит что-то еще, что не сразу видно в вашем первоначальном анализе. В любом случае управляйте MAXDEPTH и MAXMSGL так, чтобы ни одна очередь не могла заполнить файловую систему, и напишите код для обработки условий QFULL.