Верхняя граница скорости пакетной передачи в канале? - PullRequest
Новая
       26

Верхняя граница скорости пакетной передачи в канале?

0 голосов
/ 16 декабря 2018

Мы используем MQ (7.1.0.3, да, это старая версия, и мы планируем обновление до v9 в ближайшее время .....) для Q-Replication, и недавно обнаружен дроссель переноса уровня MQ.В частности, сообщения застряли в XMITQ и не могут быстро перейти на другую сторону.Мы так долго использовали настройки по умолчанию для каналов SDR и RCVR, и теперь понимаем, что MQ-настройка, вероятно, становится необходимой для увеличения громкости Q-Replication.

Мы понимаем, что batch обрезается при выполнении любого из следующих условий

  • BATCHSZ (50) достигнуто;
  • BATCHLIM (5000KB) достигнуто;
  • SDR Q пусто (это менее вероятно, что мы испытали, поскольку резервное копирование XMITQ было довольно высоким ....).

Вопрос в том, как часто MCA на стороне отправителя отправляет batch на другую сторону (без беспокойства о трубопроводах, мы все еще находимся на v7.1, которая, кажется, не имеетособенность трубопровода в любом случае).Отправляется ли batch сразу после его резки или он должен ждать, пока предыдущая доставка batch не будет завершена?

Мы пытаемся оценить теоретическую максимальную скорость MQ-передачи, учитывая известное время пинга в сети (~ 20 мс) и относительно стабильную производительность MQ на стороне RCVR.

Кстати, он находится на RedHat около версии 6.8 (не могу вспомнить точную версию, я не системный администратор ....).

1 Ответ

0 голосов
/ 17 декабря 2018

Живая публикация, обновляющая наши выводы

  1. MAX_TRANS может не быть точной, и, вероятно, пробел нам не очень поможет.MAX_TRANS контролирует скорость, с помощью которой QCapture отправляет сообщения в sendQ (IBM KC ссылка ).Наша проблема - это скорость передачи MQ.С нашим конфигом "TRANS_BATCH_SZ=1 + MAX_TRANS=128 + COMMIT_INTERVAL=500 + MONITOR_INTERVAL=30000" (все собраны из журнала qcapture, уверен, что они используются в конфигурации), мы ожидаем, что MQ_MESSAGES не больше, чем около 8K (128tx / sec * 2 * 30sec), но на самом деле наша IBMQREP_CAPQMON.MQ_MESSAGES постоянно превышает 20K большую часть времени .... Также возможно, что эти дополнительные сообщения являются результатами больших объектов, так как мы используем LOB_SEND_OPTION=S, чтобы избежать проблем с обработкойОшибка LOB_TOO_BIG ....
  2. больше 1 trans_batch_size требует LOB_SEND_OPTION=I (IBM KC link ), что является для нас блокировщиком.

  3. [добавлено 20 декабря] Мне пришла в голову интересная мысль: , если вторая партия не построена , пока не вернется предыдущий пакет ACK, и предположим, чтопосле корневая проблема может возникнуть со стороны SDR.

    • на стороне SDR требуется (относительно) фиксированное время для добавления сообщения в пакет (например, 0,95 мс);
    • фиксированное время пинга 20 мс;
    • 0 задержка на стороне RCVR, что означает, что сторона RCVR немедленно отправляет ACK.

    При использовании по умолчанию BATCHSZ=50, этопотребовалось бы 0.95ms*50+20ms=67.5ms для каждой партии, чтобы получить, приблизительно, 14.8 batch/sec или 14.8*50=740 msg/sec;

    Используя BATCHSZ=100, для завершения каждой партии потребуется 0.95ms*100+20ms=115ms, получая около 8.7 batch/sec или 8.7*100=870 msg/sec.

    Эти цифры, кажется, соответствуют нашему наблюдению / эксперименту, но необходимо проверить, верны ли предположения.

...