О брокере базы данных OpenEdge

Что такое брокер OpenEdge?

Брокер базы данных OpenEdge - это progress-процесс, задача которого управлять доступом к базе данных, запущенной в многопользовательском режиме. Неважно, подключаются клиентские сессии к базе непосредственно или удаленно через сервера,  для координации действий все они используют брокера.

Фактически брокер делает не так уж и много:

• Отвечает за выделение и форматирование разделяемой памяти во время запуска базы, а также за выполнение процесса Crash Recovery.
• «Слушает» запросы удаленных клиентов (remote client) на установление подключения к базе данных и направляет новые клиентские процессы для обработки на сервера, запуская при необходимости дополнительные сервера. Брокер также контролирует запросы от локальных клиентов (self-service client), удовлетворяя или отклоняя их.
• Выполняет принудительное отключение пользователей от базы данных, например, при возникновении аварийной ситуации.

Разделяемая память брокера

Название «разделяемая память» говорит сама за себя – это выделенная область оперативной памяти, которую одновременно могут использовать множество процессов. Необходимость в использовании разделяемой памяти возникает когда:

• к одним и тем же данным в памяти должно обращаться множество процессов, тем самым исключается дублирование данных в памяти;
• измененные данные должны немедленно стать доступны другим процессам, исключая временные задержки, связанные с обработкой внесенных изменений.

Оба этих условия всегда присутствуют при нормальной активности базы данных.

Созданная брокером область разделяемой памяти может состоять из нескольких сегментов, которые создаются, если размер предоставляемой брокеру области разделяемой памяти будет больше максимального размера сегмента памяти в операционной системе. Минимальный размер сегмента разделяемой памяти равен 128 Мб для 32-битных платформ и 1024 Мб для 64-битных. Узнать, сколько сегментов было выделено базе данных, можно с помощью команды proutil -C dbipcs. Алгоритм распределения памяти СУБД OpenEdge «старается» оптимально рассчитать размер сегмента разделяемой памяти в зависимости от общего её размера. Имеется возможность зафиксировать размер сегмента с помощью параметра запуска брокера <-shmsegsize>. Принудительное увеличение размера сегмента может повысить производительность системы, поскольку уменьшается количество этих сегментов, что в свою очередь требует выделения меньших ресурсов для управления ими. Обычно вам не стоит беспокоиться о размерах сегментов. Всё, о чём вы должны думать - об общем размере выделяемой памяти, управлять которым можно с помощью параметров запуска брокера. Внимание: остерегайтесь выделения базе данных большего объема памяти, чем доступно физически.

Содержимое разделяемой памяти брокера

Область разделяемой памяти содержит множество различных структур данных, управление размером и поведением которых осуществляется с помощью параметров запуска базы данных. Наиболее важные компоненты разделяемой памяти представлены в следующей таблице:

Буферный пул (buffer pool) или первичный буферный пул (primary buffer pool) – наибольшая область разделяемой памяти. Это первое, на что следует обратить внимание при возникновении проблем с производительностью. В больших промышленных системах буферный пул может занимать до 95% пространства разделяемой памяти, необходимого брокеру. Буферный пул – это кэш базы данных, в который считываются блоки базы данных с дисков. Аналогичный принцип применяется операционной системой при кэшировании дисков. В результате все чтения и изменения блоков данных выполняются в оперативной памяти, не требуя дискового доступа, следовательно, операции с данными в памяти выполняются в сотни раз быстрее. У буферного пула есть метрика «buffer hit rate». Эта метрика показывает, насколько эффективно используется буферный пул, отображая в процентном отношении количество раз, когда блок с данными был обнаружен в буферном пуле. Перевести «buffer hit rate» можно как «частота успешных обращений к буферному пулу». Чем больше размер буферного пула, тем больше блоков базы данных размещено в памяти, тем выше значение «buffer hit rate». Размером буферного пула управляет параметр запуска базы данных <-B n>, где n – количество блоков базы данных.

Буферный пул содержит блоки, которые значительно рассеяны в пределах буферного пула, т.е. они не размещаются в памяти в каком-то конкретном порядке. Поэтому, когда сервер или клиентский процесс обращается с запросом на чтение блока, должен быть способ быстрого поиска требуемого блока в памяти, и если блок найден, необходимо определить, где в буферном пуле он размещен. Это задача хэш-таблицы (hash table). Соотношение размера хэш-таблицы и буферного пула определяет его эффективность. Чем больше размер хэш-таблицы, тем быстрее выполняется поиск блоков. Размером хэш-таблицы управляет параметр запуска базы данных <-hash n>.

Альтернативный буферный пул (Alternate Buffer Pool) – аналог первичного буферного пула. Введен в версии OpenEdge 10.2B. Альтернативный буферный пул используется для улучшения производительности за счет размещения в нём наиболее часто используемых блоков объектов базы данных или блоков, шифруемых механизмом Transparent Data Encryption. Такие блоки не будут «выселяться» из памяти для освобождения места другим блокам, которые могут в отличие от них понадобиться только один раз. Это уменьшает интенсивность дискового ввода/вывода, а при включенном механизме Transparent Data Encryption исключает издержки, связанные с многократным шифрованием и дешифрованием блоков при дисковой записи/чтении. Размер альтернативного буферного пула исчисляется в блоках базы данных и устанавливается параметром запуска базы <-B2>. По умолчанию размер альтернативного буферного пула нулевой. Использование альтернативного буферного пула требует от администратора кроме установки параметра <-B2> дополнительных действий по настройке объектов базы данных, которые будут использовать альтернативный буферный пул.

Таблица блоков (block table) – это элемент разделяемой памяти, содержащий информацию о состоянии каждого блока. Возможные состояния:

• «пустой»
• «используемый, но чистый»
• «грязный» (готов к записи на диск) и т.п.

Таблица блоков имеет фиксированный размер, который зависит от размера буферного пула.

В области разделяемой памяти размещаются буферы механизмов Before-Imaging и After-Imaging, буферы After-Imaging размещаются только, если включен сам механизм. Буферы BI/AI используются для промежуточного хранения информации, предназначенной для соответствующих файлов (BI-файлы/AI-файлы). Размер буферов определен размерами bi- и ai-блока. Количество буферов устанавливается параметрами запуска базы данных <-bibufs n> и <-aibufs n>. Если в promon видно, что системе не хватает пустых буферов, то их количество необходимо увеличить.

Таблица процессов (process table) содержит список всех процессов, подключенных к базе данных, таких как: брокеры, серверы, apw, biw, aiw, watchdog, сессии promon и клиентские сессии. Таблица содержит информацию о каждом пользователе; ID его процесса; тип устройства, с которого он подключился, и прочую важную информацию. Размер этой таблицы основывается на количестве подключений к базе данных, которое вы устанавливаете параметром запуска базы данных <-n>.

Таблица транзакций (transaction table) – имеет тот же размер, что и таблица процессов, т.к. у каждого процесса в один момент времени может быть только одна активная транзакция. Однако у каждой подключенной сессии может быть большое количество блокированных записей, чтобы отслеживать эти блокировки брокер имеет таблицу блокировок (lock table), размер которой регулируется параметром запуска базы данных <-L>.

Таблица серверов (server table) – содержит информацию о серверах, связанных с базой данных, включая: количество подключенных через каждый сервер пользователей; портах для связи с серверами; протоколах, используемых на этих портах; и т.п. Количество серверов, которые может создать брокер, настраивается параметрами запуска брокера <-Ma>, <-Mi> и <-Mn>.

Примечание: начиная с версии OpenEdge 10.1С параметры запуска базы данных <-B>, <-bibufs>, <-aibufs> и <-L> можно увеличивать на работающей базе данных без её остановки. Для этого используется команда proutil <dbname> -C increaseto <parametrs>.