Производительность Source-базы и параметр -pica

Производительность репликационной Source-базы данных падает во время больших объемом записи в ней? Давайте разберемся в причине, и найдем решение.

Итак, симптомы:

• Пользователи жалуются на резкое снижение времени отклика от базы данных.
• Мониторинг Target-базы (dsrutil db-name -C monitor) показывает значительное отставание Target от Source, и разрыв продолжает увеличиваться.
• Мониторинг очереди сообщений (promon > R&D > 1 >16 Database Service Manager) показывает, что в очереди нет места, либо очень мало - Free Message Entries : 0

Что имеем по настройкам:

• Очередь IPC Queue Size (-pica) имеет максимальное значение 8192 (для >10.1).
• AI-экстенты имеют фиксированный размер.
• AI-экстенты получают статус LOCKED после переключения.
• Размер AI и BI блоков одинаковый – 16KB
• Используется асинхронный режим репликации

Что происходит?

Как только очередь DBService заполнится, производительность базы данных упадет, потому что репликация не будет успевать получать подтверждения о применении заметок.

Когда процесс сервера репликации работает, он использует буфер для сохранения указателей на AI-блоки в AI-экстентах по мере их заполнения. Последовательность заполнения этого буфера называется Database service manager queue (RPLS-Q), размер этой очереди зависит от параметра старта базы данных -pica и размера AI-блока. Это фактически очередь FIFO, которая позволяет Source и Target базам выполнять асинхронную буферизованную передачу данных между ними. 

Когда этот буфер заполнится, база данных вынуждена ожидать очередного указателя до тех пор, пока очередной AI-блок не будет реплицирован и указатель не освободится, только после этого будет позволено продолжить запись в AI-экстент. Если pica-буфер заполнен из-за сетевых проблем или имеются проблемы с задержкой, и в тоже время сервер репликации все еще работает, требуя новых указателей в очереди, то он не может реплицировать новые AI-блоки в Target-базу по мере их заполнения, поэтому транзакционная активность Source-базы «замораживается» поскольку AI-заметки о транзакциях не могут записываться. 

Когда же процесс сервера репликации остановлен, он не заполняет pica-буфер указателями на заполненные AI-блоки. Вместо этого происходит накопление данных в AI-экстентах для их обработки позднее. При этом заполненные AI-экстенты получают статус LOCKED. Как только сервер репликации будет стартован и подключен к его агентам, процесс репликации содержимого LOCKED-экстентов продолжится.

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

Решение проблемы

Самое быстрое решение проблемы производительности в этой ситуации является прекращение работы процесса сервера репликации (dsrutil db-name –C terminate server). Но помните! У вас должно быть достаточное количество AI-экстентов, чтобы уместить весь объем AI-заметок за время простоя сервера репликации, и лучше, чтобы AI-экстенты были переменного размера.

Второй способ - увеличить размер pica-буфера. Но здесь проблема в том, что до версии OpenEdge 10.2B07 максимальное значение picа равно 8192. Поэтому у вас есть несколько вариантов. Первый, перейти на версию OpenEdge 11.2 или 11.3 и выше. Второй, дождаться выпуска Service Pack 08 на OpenEdge 10.2B08 (осень 2013 г.). Либо заказать Hot Fix на OpenEdge 10.2B07. Почему? В этих версиях размер pica-буфера увеличен до 1 000 000 (!).

Понятно что, такое обновление возможно только в случае, если вы находитесь на официальной технической поддержке Progress Software. Получить обновление можно обратившись к официальному дистрибьютору Progress Software в России, к компании Progress Technologies.

Что бы хотелось добавить в завершении

1. После обновления на новую версию, крайне не рекомендую бросаться во все тяжкие, увеличивая pica сразу до 1 000 000. Подбирайте нужное значение опытным путем.

2. Большой размер pica-буфера накладывает определенные риски связанные с синхронизацией source и target в случае сбоя на Source базе, так как больше AI-блоков будет находиться «в пути» между source (RPLS) и target (RPLA) одновременно.

3. В приложении, где используется множество подключенных репликационных баз данных, важно установить одинаковое значение pica для всех этих баз, т.к. если хоть в одной, даже минимально используемой базе данных, pica-буфер будет заполнен, это повлияет на паузы в работе всего приложения.

4. Для систем, использующих OpenEdge Replication версии 10.1С ,или более ранних, крайне рекомендуется обновиться до версии OpenEdge 10.1C02 (лучше сразу по возможности до 11.3, в крайнем случае до 10.2B08), поскольку с тех пор были сделаны значительные изменения в архитектуре, которые снижают нагрузку связанную с репликацией примерно на 40% (!), тем самым снижая воздействие очереди сервера репликации на производительность.

Успешной защиты ваших данных!