Репликация от сервера к серверу и процессор и 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? мы могли бы по крайней мере тогда отправить предупреждение.

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

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