Я приведу несколько замечаний в этом ответе, но на основе любых дальнейших отзывов я могу добавить больше.
Вы используете очень старую версию программного обеспечения на стороне отправителя, MQ 7.5 потерял поддержку почти на два года go (30 апреля 2018 года). IBM за дополнительную плату предоставит расширенную поддержку еще на три года, поэтому, возможно, вы попадете в эту группу. Сам сервисный релиз 7.5.0.2 вышел 11 июля 2013 года, так что на данный момент ему почти семь лет. Я настоятельно рекомендую вам перейти на более новую версию.
Обратите внимание, что MQ v8.0 выходит из поддержки 30 апреля 2020 года, и IBM только что через несколько дней объявила go, что MQ v9.0 выходит из поддержка 30 сентября 2021 г. Когда вы выполняете миграцию, вам следует go с 9.1, у которой нет объявленного окончания поддержки (они дают минимум пять лет, поэтому может быть 2023), или go со следующей версией MQ, которая должна выйти когда-нибудь в этом году.
Вы упоминаете настройку следующего:
TCP:
SvrSndBuffSize=0
SvrRcvBuffSize=0
Вышеуказанные настройки применяются к концу SVRCONN клиентского соединения. Это можно увидеть на странице Центра знаний MQ v7.5 WebSphere MQ> Конфигурирование> Изменение информации о конфигурации> Изменение информации о конфигурации администратора очередей> TCP, LU62, NETB IOS и SPX :
SvrSndBuffSize = 32768 | number
Размер в байтах буфера отправки TCP / IP, используемого серверной частью канала подключения к клиентскому соединению .
SvrRcvBuffSize = 32768 | number
Размер в байтах буфера приема TCP / IP, используемого серверной частью канал подключения к клиентскому соединению.
В IBM MQ v7.5.0.2 APAR IV58073 представил концепцию установки различных настроек буфера в значение 0, что означает, что это позволит использовать операционную систему по умолчанию. К сожалению, как и многие вещи в Центре знаний, похоже, что IBM не документировала это правильно для 7.5.
Однако вы можете просмотреть Центр знаний IBM MQ v8.0, чтобы получить полную картину этих настроек на странице Настройка> Изменение информации о конфигурации> Изменение информации о конфигурации администратора очередей> TCP, LU62 и NETB IOS, в частности, вы хотите настроить эти два параметра так, чтобы они влияли на ваш канал отправителя:
SndBuffSize = число | 0
Размер в байтах буфера отправки TCP / IP, используемого отправляющим концом каналов . Это значение раздела может быть переопределено разделом больше спецификаций c для типа канала, например RcvSndBuffSize. Если значение установлено равным нулю, используются значения по умолчанию операционной системы. Если значение не задано, используется значение по умолчанию IBM MQ 32768.
RcvSndBuffSize = number | 0
Размер в байтах буфера отправки TCP / IP, используемого отправителем конца канала получателя. Если значение установлено равным нулю, рабочая операция системные значения по умолчанию используются. Если значение не задано, то используется значение по умолчанию IBM MQ 32768.
Начиная с IBM MQ v8.0, любой вновь созданный администратор очередей будет иметь все перечисленные ниже значения в qm.ini:
TCP:
SndBuffSize=0
RcvBuffSize=0
RcvSndBuffSize=0
RcvRcvBuffSize=0
ClntSndBuffSize=0
ClntRcvBuffSize=0
SvrSndBuffSize=0
SvrRcvBuffSize=0
Однако любой обновленный администратор очередей по умолчанию не получит эти настройки, то есть, если они отсутствуют, они не будут добавлены, если они присутствуют, они останутся прежними. Если этот параметр отсутствует, то, как сказано выше, «по умолчанию используется IBM MQ 32768».
Я провел обширные обсуждения с поддержкой IBM по этой теме c и пришел к выводу, что они это сделали. не вижу причин, чтобы не устанавливать его на 0, они увидели только выгоду в этом, но с большой осторожностью они не меняют его на 0.
Я бы порекомендовал вам добавить все эти ваш qm.ini, но как минимум добавьте два, которые я выделил выше.
Это хорошая настройка для реализации, но она может не решить вашу проблему, если за последнее время ничего не изменилось ни с одной стороны. Однако если что-то изменилось, например, разница в сети, или MQ был обновлен до 8.0.0.8 на удаленной стороне, то этот параметр может просто решить вашу проблему.
В состоянии канала выведите два значения интересны:
NETTIME(2789746,3087573)XQTIME(215757414,214033427)
NETTIME означает, что на основании недавних действий для получения ответа от оператора потребовалось 2,7 секунды Канал RCVR, в течение более длительного периода времени требовалось 3,1 секунды для получения ответа от канала RCVR. Можете ли вы сравнить это с пингом TCP от сервера канала отправителя к серверу принимающего канала, 2,7 секунды для ответа по сети кажется чрезмерным. В презентации Поддержание и работа каналов MQ, представленной на технической конференции Capitalware MQ v2.0.1.4 , Пол Кларк, который раньше работал в IBM, заявляет: «NETTIME измеряет только сетевое время и не включает MQCMIT для пример ".
XQTIME означает, что, основываясь на недавней активности и в течение более длительного периода времени, сообщение на XMITQ было получено каналом SDR для отправки.
См. Ниже, как IBM документирует это:
NETTIME
Количество времени, отображаемое в микросекундах, для отправки запроса на удаленный конец канала и получения ответ. Это время измеряет только сетевое время для такой операции. Отображаются два значения:
- Значение, основанное на недавней активности за короткий период.
- Значение, основанное на активности за более длительный период.
XQTIME
Время в микросекундах, в течение которого сообщения оставались в очереди на передачу до получения. Время измеряется с момента, когда сообщение помещается в очередь передачи, до его извлечения для отправки по каналу и, следовательно, включает любой интервал, вызванный задержкой в приложении для размещения.
Отображаются два значения:
- Значение, основанное на недавней активности за короткий период.
- Значение, основанное на активности за более длительный период.
Информация параметр канала BATCHSZ можно найти на странице Центра знаний IBM MQ v8.0 Справочник> Ссылка на конфигурацию> Атрибуты канала> Атрибуты канала в алфавитном порядке> Размер пакета (BATCHSZ) . Я процитировал его и выделил несколько областей полужирным шрифтом .
Этот атрибут - максимальное количество сообщений, которые должны быть отправлены до получения точки syn c.
Размер пакета не влияет на то, как канал передает сообщения; сообщения всегда передаются по отдельности, но принимаются или возвращаются в виде пакета.
Чтобы повысить производительность, вы можете установить размер пакета, чтобы определить максимальное количество сообщений, передаваемых между двумя точками синхронизации c. Размер пакета, который будет использоваться, согласовывается при запуске канала, и берется меньшее из двух определений канала. В некоторых реализациях размер пакета рассчитывается по наименьшему из двух определений канала и двум Диспетчер очереди значений MAXUMSGS. Фактический размер партии может быть меньше; например, пакет завершается, когда в очереди на передачу не осталось сообщений или истекает интервал между пакетами.
Большое значение для размера пакета увеличивает пропускную способность, но время восстановления увеличивается, поскольку существует больше сообщения для возврата и повторной отправки. По умолчанию BATCHSZ равен 50, и вам рекомендуется сначала попробовать это значение. Вы можете выбрать более низкое значение для BATCHSZ, если ваши сообщения ненадежны, что повышает вероятность восстановления.
Этот атрибут действителен для типов каналов:
- Отправитель
- Сервер
- Получатель
- Запрашивающий
- Отправитель кластера
- Кластерный приемник
Ответы на вопросы:
- Являются ли сообщения, отправленные на этот XMITQ, постоянными?
Ответ: Да , в нашей PROD env все сообщения являются непоследовательными. - Был ли у вас недавний рост объема при переходе на этот XMITQ?
Ответ: Нет, мы используем инструменты мониторинга, мы извлекли отчет, который показывает очень похожие частота сообщений в течение периода. Тот же показатель за последние 2 недели. - Устанавливаются ли приложения для установки
MQPMO_SYNCPOINT, а затем фиксируются после того, как 1 или более сообщений помещаются в очередь?
Ответ: Я проверю с командой приложения.