Доступ к общей памяти базы данных в средах с несколькими процессорами

На всех платформах, поддерживаемых Progress и OpenEdge, архитектура с несколькими процессорами неявно поддерживается до тех пор, пока операционная система хоста также обеспечивает гарантированную поддержку многопроцессорности.

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

В модели CC-NUMA система показывает пользователю только один образ памяти, даже если память физически распределена по процессорам. Так как процессоры могут получить доступ к своей собственной памяти гораздо быстрее, чем к памяти других процессоров, доступ к памяти является неравномерным (NUMA). Движок баз данных OpenEdge основан на общей разделяемой памяти, что означает, что процессоры должны тратить значительное время ядра (высокие значения %sys) только для того, чтобы убедиться, что все процессоры имеют согласованный образ сегментов общей памяти. По состоянию на конец 2018 года Progress Software не реализовывало какую-либо оптимизацию для архитектуры NUMA.

Реализация семафоров операционной системы в системах SMP/NUMA во многом зависит от вендоров. Далее приведена техническая дискуссия, сохранившаяся из исследований специалистов Progress и RedHat, однако тоже самое было обнаружено и для других разновидностей Linux и Windows.

СУБД OpenEdge использует общую память для координации изменений базы данных между несколькими пользователями. Общая память (разделяемая память) – это стандартный метод предоставления общего буферного пула, доступного нескольким процессам. Изменения контролируются набором латчей, которые используются для управления обновлениями и предотвращения неправильного вмешательства процессов друг в друга.

В случае использования редакции СУБД OpenEdge Enterprise для реализации латчей используется метод спин-локировок. Спин-локировки работают с минимальным взаимодействием с самой ОС, что позволяет им масштабироваться до множества CPU с незначительным добавлением накладных расходов на CPU, так как координация блокировок происходит на уровне аппаратной синхронизации CPU и памяти. Спин-локировки реализованы всего в нескольких инструкциях кода и встроены непосредственно в сам менеджер базы данных. Это тот же самый метод, которые операционные системы используют для внутренних механизмов блокировки.

В случае использования редакции OpenEdge Workgroup используется методика, опирающаяся на семафоры операционной системы. Семафор отличается от спин-локировки тем, что операционная система управляет синхронизацией и нам необходимо обратиться к ОС чтобы реализовать код латча, которые спин-локировка делает в нескольких собственных инструкциях. Из-за накладных расходов на переключение контекста ОС, а также из-за добавленных инструкций в самом сервисе семафоров, семафоры работают менее эффективно.

В однопроцессорной системе производительность Workgroup -базы данных будет достаточно хорошей, потому что сама СУБД имеет оптимальные алгоритмы, а добавленный код для семафоров в такой системе не вносит серьёзных ограничений.

В многопроцессорной системе, для примера с четырьмя ядрами, вызов из базы данных Workgroup оправляется в ОС, а затем должен быть согласован в программном обеспечении с запросами семафора, поступающими от процессов, работающих в трёх других CPU. Всё это делается на уровне операционной системы, и это гораздо сложнее и дороже в плане накладных расходов, чем просто несколько инструкций, которые проверяют и устанавливают блокировки в приложении на прямую. Согласование изменений на уровне семафора является дорогостоящей операцией, которая становится всё медленнее и медленнее по мере добавление CPU, потому что структуры данных должны многократно блокироваться, обновляя структуры данных, которые поддерживает ОС для реализации семафоров. Накладные расходы от использования семафоров распределены между вызовами операционной системы, контекстными переключателями, множество спин-локировок и сложными алгоритмами разрешения конфликтов.

Производительность семафоров зависит от операционной системы из-за различных реализаций. RedHat сообщает, что семафоры являются значительно более медленными механизмами, чем спин-локировки на RedHat GNU/Linux, и что они плохо масштабируются. Семафоры в Windows, похоже, работают быстрее, чем в Linux, и, похоже, масштабируются немного лучше, но всё же демонстрируют те же проблемы производительности.

Код СУБД OpenEdge в основном является потребителем услуг операционной системы, которые используются настолько эффективно и просто насколько это возможно, чтобы достичь лучшей надёжности и высокой степени переносимости. Некоторые сервисы менее эффективны в некоторых реализациях ОС, некоторые медленнее на основе аппаратной архитектуры. RedHat справедливо отмечает, что на производительность Workgroup влияет архитектура нынешних процессоров на базе Intel и расходы на использование семафоров Linux в среде SMP. Это ограничение не относится к продукту OpenEdge.

Таким образом, для оптимизации производительности OE Enterprise с архитектурой памяти NUMA рекомендуется:

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

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

• Используйте редакцию OpenEdge Enterprise для получения преимуществ от использования спин-локировок вместо семафоров.
• Установите правильное значение для параметра старта базы данных -spin.