Сервер на сервер репликации и процессора и 32k \ коррумпированных документов

Резюме: если база данных содержит документ с проблемой 32K или поврежден, при репликации с сервера на сервер это вызывает заметное увеличение ЦП в задаче nserver.exe, что фактически приводит к замедлению нашего сервера (ов).

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

Из серверов в кластере 1 считается «концентратором» и имитирует репликацию PUSH-PULL со своими партнерами по кластеру каждые 60 минут, так что нагрузку репликации берет на себя концентратор, а не партнеры кластера.

У нас есть проблема: время от времени мы получаем медленное время репликации от концентратора до партнера по кластеру, иногда до 30 минут. Это максимизирует задачу nserver.exe на «партнере кластера», что заставляет его очень медленно отвечать на HTTP-запросы.

В прошлом мы обнаружили, что если поврежденный документ находится в базе данных, это может иметь такое влияние, но в таких случаях журнал сервера будет показывать поврежденный документ noteId, и мы запускаем исправление, все хорошо. Но сейчас мы не видим никаких записей о поврежденных документах. Мы заметили, что если присутствует документ с проблемой 32K, может произойти то же самое. Единственное решение в этом случае - запустить команду: fixup mydb.nsf -V, которая показывает, что очищается документ размером 32 КБ. К счастью, у нас есть обратный прокси-сервер, поэтому мы можем выключить HTTP-серверы так, чтобы пользователи не заметили этого, но пользователи замечают, когда на сервере возникает проблема!

Кто-нибудь еще видел это?

Я настроил обработчики событий DDM для многих событий репликации. Я установил предел времени ожидания репликации на 5 минут (максимум, который мы обычно видим при полной пользовательской нагрузке, составляет 0,1 минуты), чтобы предотвратить повторение репликации в течение 30 минут, как и раньше. Это временная работа.

Кто-нибудь знает о событии DDM для устранения проблемы 32K? мы могли бы хотя бы послать предупреждение.

Что касается проблемы 32K: для этой проблемы нужен другой поток, но нам относительно сложно найти источник проблемы, поскольку событие 32K встречается довольно редко. Наше приложение довольно сложное, взаимодействует с различными другими внешними веб-сервисами с двусторонней передачей данных. Но если мы столкнемся с документом размером 32 КБ, мы не сможем просмотреть свойства поля, поэтому мы не сможем определить, в каком поле есть проблема, которая дала бы нам понять, какой процесс является виновником. Как и выше, мы запускаем исправление -V.

Любая помощь \ комментарии по этому поводу будут с благодарностью приняты.