Параметры старта разделяемой памяти

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

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

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

Разделяемая память

Разделяемая память представляет собой область в памяти компьютера, на котором располагается база данных. СУБД OpenEdge использует разделяемую память для обеспечения одновременного доступа к базе данных множеству пользователей. В частности, разделяемая память используется для:

• хранения запрошенных пользователями данных, которые были извлечены с диска;
• обеспечения возможности пользователям изменять данные в памяти;
• сбора заметок о транзакциях в базе данных;
• хранения изменённых данных, которые должны быть записаны на диск.

Рассмотрим параметры настройки разделяемой памяти.

Semaphore Sets

Как правило, в многопользовательской среде множество процессов базы данных конкурируют за доступ к одним и тем же ресурсам разделяемой памяти, таким как буферный пул, буферы Before-Image и After-Image и таблицы разделяемой памяти (Lock, Hash, Transaction и т.п.). По умолчанию процессы используют семафоры для приобретения локировки на эти общие ресурсы или для ожидания разрешения конфликтов при попытке получить локировку. Семафоры эффективны для ожидания выполнения длительных задач (дольше, чем несколько миллисекунд), например, таких как транзакции базы данных.

В зависимости от окружающей среды, администратору может потребоваться настроить параметры старта, отвечающие за семафоры. Если используется операционная система Windows или с базой работает более 1000 пользователей, то не нужно беспокоиться о настройке семафоров. Однако, если используется UNIX и количество пользователей более 1000, то необходимо добавить дополнительные наборы семафоров, чтобы уменьшить конкуренцию и тем самым повысить производительность.

СУБД OpenEdge использует два типа семафоров, Login (для подключения) и User (для пользователей). По умолчанию при старте базы данных, СУБД размещает три набора семафоров, один для подключения и два для пользователей.

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

Синтаксис параметра старта для запроса дополнительных семафоров:

-semsets <кол-во наборов семафоров> -n <кол-во подключений>

Предположим, что в UNIX нам необходимо 4 набора семафоров для базы данных sports, один для входа в систему и три набора для 3 000 пользователей. В этом случае в файле параметров старта базы данных необходимо указать следующие значения:

-semsets 4
-n 3000

Spin Lock Retries

В то время, как семафоры эффективны для ожидания выполнения длительных задач, они не подходят для ожиданий выполнения задач краткосрочных. По умолчанию семафоры применяются для ожидания обоих типов задач. Но если у вас многопроцессорная система с лицензией OpenEdge Enterprise RDBMS, то вы должны настроить механизм спин-локировки (spin locks) для обеспечения эффективной работы краткосрочных операций.

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

Для настройки спин-локировки применяется параметр старта Spin Lock Retries (-spin). С помощью этого параметра указывается сколько раз процесс будет пытаться получить локировку (так называемый «спиннинг») на занятый ресурс разделяемой памяти прежде, чем будет сделана пауза. После того, как процесс будет поставлен на паузу, через заданное количество миллисекунд он «проснётся» и попытается получить локировку снова.

Если у вас медленный процессор и у параметра -spin было установлено слишком высокое значение, то это может привести к снижению производительности. Поэтому необходимо осторожно подбирать правильное значение.

Синтаксис параметра -spin:

-spin <number>

Учитывая, что современные процессоры очень быстрые, то исходя из лучших практик рекомендуется установить начальное значение параметра -spin равным 10 000, после чего выполнять мониторинг работы базы данных.

Эффект от применения спин-локировки можно наблюдать с помощью монитора Progress (утилита PROMON -> R&D -> 3. Other Displays -> 1. Performance Indicators). Параметр -spin контролирует метрика Latch timeouts. Повышение значения параметра -spin приводит к уменьшению значения Latch timeouts. Не стоит увлекаться и завышать значение параметра слишком высоко, так как в определённый момент значение метрики Latch timeouts прекратит уменьшаться, и если вы продолжите увеличение, то это отрицательно повлияет на загрузку CPU и приведёт к обратному эффекту, т. е. к ухудшению производительности.

Pin Shared Memory

Для обеспечения хорошей производительности администратор базы данных должен убедиться в том, что система, на которой работает СУБД OpenEdge, имеет достаточно памяти.

По умолчанию, если в системе недостаточно свободной памяти, то СУБД, вероятно, придётся сбрасывать часть содержимого памяти на диск и считывать её обратно в процессе работы пользователей – это называется подкачка страниц или swap, которая значительно снижает производительность.

Чтобы исключить сброс сегментов разделяемой памяти на диск применяется параметр старта Pin Shared Memory (-pinshm). Его использование гарантирует, что сегменты разделяемой памяти будут закреплены за базой данных в памяти.

Синтаксис параметра:

-pinshm

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

На момент написания пособия не существовало каких-либо преград для использования параметра Pin Shared Memory. Тем не менее, этот параметр не доступен для использования на операционных системах AIX и Windows, так как эти операционные системы имеют отличия в инициализации разделяемой памяти. Кроме того, возможность использования Pin Shared Memory доступна только с лицензией OpenEdge Enterprise RDBMS.

Storage Object Cache Size

Для хранения информации об объектах в общей памяти, к которым происходит наиболее частое обращение, используется Storage Object Cache, благодаря чему эти объекты могут быть быстро найдены с минимальными затратами времени.

Для повышения производительности администратор может использовать параметр Storage Object Cache Size (-omsize), чтобы указать количество объектов, описание которых следует сохранять в кэше. Значение этого параметра учитывает все таблицы, индексы, BLOB и CLOB.

По умолчанию значение параметра -omsize равное 1024. Допустимые значения находятся в диапазоне от 13 до 6 553 500.

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

select count(*) from _storageobject

Если количество объектов менее 1024, то никаких изменений не требуется. Если же общее количество объектов больше, чем 1024, то чтобы учесть возможные изменения в схеме базы данных в будущем, необходимо увеличить полученное значение на 20% и использовать результат в качестве значения параметра -omsize.

Синтаксис параметра Storage Object Cache Size (-omsize):

-omsize <размер кэша>

Сегменты разделяемой памяти (UNIX)

В UNIX разделяемая память делится на сегменты (в Windows вместо сегментов используются отображаемые в память файлы (memory mapped files)). Когда СУБД OpenEdge выполняет старт базы данных, то сначала вычисляются размеры сегментов разделяемой памяти путём анализа значений параметров старта и размеров и количества различных структур данных, которые будут отображаться в разделяемой памяти. После этого СУБД попытается выделить максимально возможный размер сегмента и наименьшее количество сегментов для удовлетворения требований к разделяемой памяти. Как правило, несколько крупных сегментов обеспечивают более высокую производительность, чем множество небольших сегментов.

Для повышения производительности можно использовать параметр старта Shared Memory Segment Size (-shmsegsize), с помощью которого задаётся максимальный размер сегмента. За счёт увеличения размера сегмента разделяемой памяти происходит уменьшение количества выделенных сегментов, тем самым сокращая количество системных ресурсов, необходимых для управления сегментами. При этом, если разделяемая память требует меньше памяти, чем заданное значение параметром -shmsegsize, то выделено будет только необходимое количество.

Для установки значения параметра Shared Memory Segment Size (-shmsegsize) обычно руководствуются следующими рекомендациями:

• на 32-битных платформах применяется значение 1024 МБ;
• на 64-битных платформах применяется значение 2096 МБ.

Синтаксис параметра Shared Memory Segment Size (-shmsegsize):

-shmsegsize <размер сегмента в MB>