Параметры конфигурационного файла InterBase/Firebird

• LOCK_MEM_SIZE
• SEMAPHORE COUNT
• LOCK SIGNAL
• EVENT MEMORY SIZE
• DATABASE CACHE SIZE
• SERVER PRIORITY CLASS
• SERVER CLIENT MAPPING
• SERVER WORKING SIZE
• LOCK GRANT ORDER
• LOCK HASH SLOTS
• DEADLOCK TIMEOUT
• LOCK ACQUIRE SPINS
• CONNECTION TIMEOUT
• DUMMY PACKET INTERVAL
• TMP DIRECTORY
• EXTERNAL FUNCTION DIRECTORY
• TCP REMOTE BUFFER

 

LOCK_MEM_SIZE

Параметры в ibconfig

V4_LOCK_MEM_SIZE    98304
ANY_LOCK_MEM_SIZE   98304

Действие

LOCK_MEM_SIZE определяет количество памяти, выделяемое для таблицы блокировок. В случае сервера с архитектурой Classic, указываемый размер используется для начального выделения памяти, а затем таблица блокировок может расширяться во время работы, пока не займет всю свободную память. В случае SuperServer, устанавливаемый размер невозможно изменить без перезапуска сервера По умолчанию размер памяти, выделяемый для блокировочной таблицы, равен 98304 байт.

Объяснение

Во всех версиях InterBase, исключая те, которые исполняются под управлением операционной системы VMS,  конфликты распределения ресурсов разрешаются с помощью таблицы блокировок, которую ведет IB (только при использовании VMS IB пользуется его менеджером блокировок). В архитектуре Classic таблица блокировок находится в совместно используемой всеми серверными процессами памяти. В архитектуре SuperServer таблица блокировок является частью самого серверного процесса.

Хотя InterBase не использует блокировки для разрешения конфликтов на уровне записей, он все же использует блокирование для того, чтобы защитить страницу БД в момент ее изменения. Под «моментом изменения» имеется в виду не блокировка во время транзакции, а блокировка страницы в момент ее непосредственного изменения, когда какой-либо клиент пишет туда данные. Помимо этого, InterBase использует блокировки, чтобы позволить одной транзакции ожидать окончания другой, если возник конфликт, а также в ряде случаев, когда требуется синхронизация.

Показания к изменению параметра

Изменение размера таблицы блокировок может повлиять на:

1. Размер кэша страниц БД. Каждая страница, помещаемая в кэш, блокируется по крайней мере один раз, а страницы, которые читаются несколькими клиентами – могут блокироваться несколько раз (этот пункт относится только к архитектуре Classic).
2. Число одновременных транзакций. Каждая транзакция имеет блокировку, которая ее идентифицирует. Блокировка используется для синхронизации транзакций, а также для того, чтобы распознать случаи, когда транзакция завершилась без подтверждения (commit) или отката (rollback).
3. События. Механизм оповещения о событиях основывается на блокировках. Число событий и число клиентов, ожидающих этих событий, влияют на размер таблицы блокировок.

 

SEMAPHORE COUNT

Параметры в ibconfig

V4_LOCK_SEM_COUNT    32
ANY_LOCK_SEM_COUNT   32

Действие

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

Таблица 1. Количество семафоров для IB на различных ОС

Операционная система	Количество семафоров по умолчанию
EPSON SEMAPHORES	10
M88K SEMAPHORES	10
UNIXWARE SEMAPHORES	10
NCR3000 SEMAPHORES	25
SCO_UNIX SEMAPHORES	25
sgi SEMAPHORES	25
IMP SEMAPHORES	25
DELTA SEMAPHORES	25
Ultrix SEMAPHORES	25
DGUX SEMAPHORES	25
DECOSF SEMAPHORES	16
Other UNIX	32

Объяснение

Семафоры используются для блокировок и сообщений о событиях. Теоретически, IB должен использовать очень маленькое количество семафоров – 32 должно быть более чем достаточно.

Показания к изменению параметра

Если в файле протокола IB interbase.log вы видите сообщения об ошибке "semaphores are exhausted", тогда следует увеличить количество семафоров.
 

LOCK SIGNAL

Параметры в ibconfig

V4_LOCK_SIGNAL    16
ANY_LOCK_SIGNAL   16

Действие

Параметр изменяет номер сигнала, используемый для обозначения конфликтов блокировок.

Объяснение

В архитектуре Classic, когда один серверный процесс блокирует страницу БД или другой ресурс, который необходим второму процессу, второй процесс сигнализирует об этом первому. Чтобы сменить номер сигнала, используется данный параметр. Значение номера сигнала по умолчанию зависит от операционной системы:
NETWARE_386  BLOCKING_SIGNAL 101
WINDOWS_ONLY BLOCKING_SIGNAL 101
All Others BLOCKING_SIGNAL SIGUSR1

Показания к изменению параметра

Сигналы имеют тенденцию «зашумляться», потому что несколько разных служб операционной системы могут использовать один и тот же сигнал. InterBase спроектирован для работы с «зашумленными» сигналами. Когда он получает сигнал, то пересылает его другим процессам-обработчикам, которые обрабатывают этот сигнал, причем с InterBase ничего не случится, если он получит сигнал и не сумеет его обработать – т. е. IB устойчив к «случайным» сигналам-шумам.

Может случиться так, что другой процесс в операционной системе использует тот же сигнал, что и InterBase. Тогда в случае, если этот процесс не сможет передать сигнал или аварийно завершится при виде сигнала, который он не может обработать, то вы увидите, что либо IB-соединение зависло, либо ошибки возникнут в другом процессе. В этом случае можно использовать параметр LOCK SIGNAL, чтобы выбрать другой сигнал.

Для систем с ОС Windows нет никакой необходимости изменять этот параметр.
 

EVENT MEMORY SIZE

Параметры в ibconfig

V4_EVENT_MEM_SIZE     32768
ANY_EVENT_MEM_SIZE    32768

Действие

Параметр устанавливает начальный размер памяти, выделенной для таблицы событий (events).

Объяснение

Таблица событий (event table) хранится в отображенной (mapped) памяти. В архитектуре Classic место под эту таблицу выделяется для каждого клиентского соединения. В архитектуре SuperServer одна таблица совместно используется всеми клиентами.

Показания к изменению параметра

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

DATABASE CACHE SIZE

Параметры в ibconfig

DATABASE_CACHE_PAGES        2048
для суперсервера
DATABASE_CACHE_PAGES        75
для классика

Действие

Этот параметр устанавливает число страниц из любой базы данных, которое может одновременно находиться в кэше. Если вы увеличиваете это значение, IB поместит больше страниц из каждой БД в кэш. По умолчанию, SuperServer помещает в кэш 2048 страниц из каждой БД в кэш, а Classic – 75 страниц на каждое клиентское соединение к БД. На 16-битных версиях Windows по умолчанию размер кэша – 50 страниц.

Объяснение

Кэш содержит страницы, которые были прочитаны из базы данных, а также вновь созданные страницы. Назначение кэша – уменьшить число чтений/записей страниц в БД путем удержания их в ОЗУ, чтобы они были «под рукой», пока подтверждение транзакции (commit) или другое событие не вынудит их быть записанными. Чем больше кэш, тем больше страниц сохраняются в памяти.

Минимальное значение кэша – 50 страниц, и максимальное – 65535. Эмпирический опыт показывает, что значения кэша более 10000 уменьшают производительность. По информации фирмы Borland, проблема снижения производительности при кэше размером более 10000 буферов ликвидирована в InterBase 6.5.

Вы можете увеличить размер кэша на уровне базы данных (в SuperServer’е) или на уровне соединения клиент/база данных путем использования параметра соединения, который можно использовать в ISQL, в Server Manager’e, в IBConsole или IBExpert.

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

Показания к изменению параметра

Если вам кажется, что ваш IB сервер работает слишком медленно и число страниц в кэше менее 10000, то увеличение размера кэша может улучшить производительность.
 

SERVER PRIORITY CLASS

Параметры в ibconfig

SERVER_PRIORITY_CLASS       1

Действие

Устанавливает приоритет для SuperServer’a на Windows/NT/2000. Значение «2» для этого параметра устанавливает высокий приоритет (HIGH_PRIORITY_CLASS) серверному процессу IB – ibserver.exe. Все остальные значения будут устанавливать серверному процессу IB значения нормального приоритета (NORMAL_PRIORITY_CLASS). По умолчанию параметр имеет значение 1.

Объяснение

Увеличивая приоритет процесса, вы можете заставить IB-сервер занимать больше процессорного времени. Если вас заботит производительность, вам лучше поставить сервер на выделенную однопроцессорную систему. Если вы рассчитываете на прирост производительности от клиентов запущенных на одной машине, в том случае, когда они используют совместную память нежели TCP, используйте многопроцессорную систему, привяжите сервер к одному процессору, а клиентов запускайте на другом.

Показания к изменению параметра

Я несколько предубеждена против этого параметра, но если хотите попробовать – то вперед ((с) Ann.W.Harrison).
 

SERVER CLIENT MAPPING

Параметры в ibconfig

SERVER_CLIENT_MAPPING        4096

Действие

Этот параметр устанавливает размер области разделяемой памяти, которая используется в Windows-системах для того, чтобы устанавливать связь между сервером и клиентом, запущенным на той же машине (локальное соединение). Размер по умолчанию – 4 Кб.

Объяснение

На Windows-системах (и только Windows) клиент, запущенный на той же машине, что и сервер, может устанавливать соединение с сервером через область разделяемой памяти, а не через TCP/IP. Используйте этот параметр для управления размером этой области.

Память выделяется блоками по 1024 байта. Приемлемый диапазон значений лежит между 1-м и 16-ю однокилобайтными блоками – то есть значение этого параметра может быть одним из – 1024, 2048, 3072, 4096, 5120, 6144, 7165, 8192, 9216, 10240, 11264, 12288, 13312, 14336, 15360, или 16384.

Показания к изменению параметра

Если у вас много памяти и локальных клиентов, то увеличение размеров области обмена (communications area) может улучшить производительность.
 

SERVER WORKING SIZE

Параметры в ibconfig

SERVER_WORKING_SIZE_MIN   0
SERVER_WORKING_SIZE_MAX   0

Действие

Этот параметр устанавливает ограничения размера рабочей физической памяти (working size), доступный SuperServer’у на платформе Windows/NT/2000. Параметр измеряется в 1-килобайтных блоках. По умолчанию, оба параметра имеют значение 0, что означает – нет ограничений.

Объяснение

Ограничивая максимальный размер рабочей памяти, можно заставить IB «упасть замертво» раньше времени из-за недостатка памяти. Увеличивая минимальный размер рабочей памяти,  вы можете заставить IB «захватывать» память тогда, когда она ему не нужна.

Показания к изменению параметра

Установка минимального размера рабочей памяти может устранить некоторые затраты на постепенное разрастание памяти сервера – то есть выделить столько памяти, чтобы серверу не пришлось больше ее увеличивать и тратить на это какие-то усилия. Установка максимального размера рабочей памяти может удержать сервер от «пожирания» всей доступной памяти на системах с малым ее количеством.  Не запускайте InterBase SuperServer на системах с малым количеством памяти.
 

LOCK GRANT ORDER

Параметры в ibconfig

V4_LOCK_GRANT_ORDER                        1

Действие

Устанавливает состояние блокировки 1 – Истина, включает сортировку блокировок. 0 – Ложь и выключает режим сортировки блокировок. По умолчанию сортировка блокировок выключена.

Объяснение

Сортировка блокировок достаточно проста, необходимо только узнать немного больше о блокировках. Когда соединение (клиент) запрашивает блокировку на объект, оно указывает в запросе определенный уровень блокировки. Уровни блокировки приведены ниже в таблице 2:
 

Таблица 2. Типы блокировок

Идентификатор типа блокировки	Английское наименование	Русский перевод наименования блокировки
#define LCK_none        0		Отсутствие блокировок
#define LCK_null        1	Existence	Блокировка существования объекта
#define LCK_SR          2	Shared Read	Совместное чтение
#define LCK_PR          3	Protected Read	Защищенное чтение
#define LCK_SW          4	Shared Write	Совместная запись
#define LCK_PW          5	Protected Write	Защищенная запись
#define LCK_EX          6	Exclusive	Эксклюзивная блокировка

Блокировка типа LCK_none на самом деле представляет собой запрос на снятие существующей блокировки. Блокировка LCK_null – это блокировка существования, которая налагается клиентским соединением. Для этого соединения важно лишь, чтобы заблокированный объект существовал.

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

Таблица 3. Таблица совместимости блокировок

	none	null	Shared Read	Protected Read	Shared Write	Protected Write	Exclusive
none	1	1	1	1	1	1	1
null	1	1	1	1	1	1	1
SR	1	1	1	1	1	1	0
PR	1	1	1	1	0	0	0
SW	1	1	1	0	1	0	0
PW	1	1	1	0	0	0	0
EX	1	1	0	0	0	0	0

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

Обычно, если объект, который какое-то соединение желает заблокировать, уже блокирован другим соединением, то выстраивается очередь доступа, причем соединения, которые желают получить уровень блокировок ниже, чем тот, что уже наложен на объект, продвигаются вперед очереди! То есть, если объект был заблокирован с уровнем Protected Read, то следующие соединения, которые запрашивают на этот объект блокировку Protected Read или ниже, передвинутся в начало очереди (точнее, пройдут без очереди), а соединения, который запрашивают блокировки уровнем выше (например, Shared Write) – будут «топтаться» в очереди. Если загрузка БД очень велика, такое поведение может привести к тому, что соединения, которые требуют высоких уровней блокировок, могут ждать неопределенно долго, потому что новые читающие соединения (которые запрашивают низкие уровни блокировки) будут постоянно прибывать и «лезть без очереди».

Показания к изменению параметра

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

LOCK HASH SLOTS

Параметр lock hash slots был удален из конфигурационного файла IB6.x, по крайней мере в SuperServer под NT. Однако исходный код для того, чтобы прочитать и интерпретировать этот параметр все еще существует.

Параметры в ibconfig

LOCK_HASH_SLOTS  101

Действие

Этот параметр определяет ширину хэш-таблицы, которая используется для поиска блокировок. По умолчанию значение этого параметра – 101. Число должно быть простым, чтобы хэш-алгоритм производил хорошее распределение. Он может быть в диапазоне от 101 до 2048.
Объяснение

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

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

OK, got that? Чем длиннее будут цепочки, подвешенные к каждому слоту, тем медленнее будет работать менеджер блокировок. В среднем каждая цепочка должна иметь не более 10 ячеек.

Показания к изменению параметра

Первым признаком для изменения этого параметра должна быть общая низкая производительность системы с большим количеством пользователей и страниц в кэше. Запустите инструмент iblockpr из директории %INTERBASE%\Bin для печати  блокировок. Если средняя длина более 10, увеличьте число хэш-слотов для этого параметра. Для начала умножьте среднюю длину цепочек на текущее число слотов и поделите на 9, а затем возьмите простое целое число, большее полученного значения (но меньшее 2048). Если вы производите подобную настройку на SuperServer’е, то необходимо также увеличить размер таблицы блокировок.
 

DEADLOCK TIMEOUT

Параметры в ibconfig

DEADLOCK_TIMEOUT 10

Действие

Этот параметр определяет число секунд, в течение которых менеджер блокировок будет ожидать разрешения обнаруженного конфликта, а по истечении этого срока конфликт будет рассмотрен как потенциальный deadlock (взаимная блокировка).

Объяснение

Применение этого параметра интенсивно тестировали около 2-х лет назад на системах, которые были такими медленными, что сегодня они не могли бы работать даже в посудомоечной машине. На данное время 10 секунд являются оптимальным интервалом. Если установить меньший интервал, то проверки на deadlock’и перегрузят компьютеры, а если более длинный – то пользователи ворвутся в вашу лабораторию и разгромят компьютеры.

Показания к изменению параметра

Deadlock’и  очень редко встречаются в InterBase’e. Обычная ошибка deadlock, ошибка обновления (Update Conflict), не является тем deadlock’ом, который обнаруживается менеджером блокировок.  Представляет интерес запрограммировать действительный случай возникновения deadlock’а (когда А изменяет строку 1, B изменяет строку 2, затем А пытается изменить строку 2, а B – строку 1, причем все это без подтверждения изменений – без commit), а затем поэкспериментировать с различными интервалами DEADLOCK_TIMEOUT, чтобы увидеть, как изменяется производительность.
 

LOCK ACQUIRE SPINS

Параметры в ibconfig

LOCK_ACQUIRE_SPINS   0

Действие

Для архитектуры SuperServer этот параметр не производит никакого действия. В архитектуре Classic только один клиент одновременно может обращаться к таблице блокировок. Доступ к таблице блокировок определяется мьютексом. Запрос мьютекса может быть либо условным – когда задержка является ошибкой и запрос  должен быть повторен, либо безусловным – когда запрос будет ожидать до тех пор, пока его не обслужат. Параметр LOCK_ACQUIRE_SPINS устанавливает число попыток выполнения условного запроса. По умолчанию – 0 (ноль).

Объяснение

Условный запрос мьютекса повторяется определенное число раз, определяемое параметром LOCK_ACQUIRE_SPINS, а затем превращается в безусловный запрос. Вроде бы это может принести пользу на машинах с несколькими процессорами (SMP). Что весьма сомнительно.

Показания к изменению параметра

Нет.
 

CONNECTION TIMEOUT

Параметры в ibconfig

CONNECTION_TIMEOUT  180

Действие

Устанавливает  время ожидания (таймаут) соединения. По умолчанию – 180 секунд.

Объяснение

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

Время ожидания также может быть указано в dpb  (database parameter block). Соответствующий параметр имеет название isc_dpb_connect_timeout.

Показания к изменению параметра

Чем выше значение этого параметра, тем меньше фиктивных запросов будут загружать сеть. С другой стороны, «мертвые» соединения будут дольше «висеть». Рекомендуется значительно увеличить значение этого параметра, если вы точно уверены, что клиентские приложения не будут некорректно завершать свою работу.
 

DUMMY PACKET INTERVAL

Параметры в ibconfig

DUMMY_PACKET_INTERVAL  60

Действие

Этот параметр  определяет, насколько часто будут посылаться фиктивные запросы для проверки того, что клиент все еще работает. По умолчанию это 60 секунд.

Объяснение

InterBase закрывает соединение, когда клиент перестает отвечать. Для того, чтобы определить, что клиент более не отвечает на запросы, IB ожидает некоторое время (определяемое параметром CONNECTION_TIMEOUT), а затем посылает фиктивный запрос для проверки соединения. Если при посылке возникает ошибка, то IB заключает, что клиент «мертв».

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

Показания к изменению параметра

Чем выше это значение, тем реже фиктивные пакеты будут появляться с сети. Но, с другой стороны, «мертвые» соединения будут дольше «висеть». Рекомендуется значительно увеличить значение этого параметра, если вы точно уверены, что клиентские приложения не будут некорректно завершать свою работу.
   

TMP DIRECTORY

Параметры в ibconfig

TMP_DIRECTORY 
TMP_DIRECTORY 20000 "/opt/interbase/tmp"

Действие

Этот параметр может использоваться в файле ibconfig несколько раз для того, чтобы определить местоположение временных файлов IB. Размер временных файлов задается в байтах. Если в ibconfig нет этого параметра, то InterBase проверяет следующие переменные окружения: INTERBASE_TMP, TMP, and TEMP.

Этот параметр доступен только для архитектуры SuperServer.

Объяснение

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

Показания к изменению параметра

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

EXTERNAL FUNCTION DIRECTORY

Параметры в ibconfig

EXTERNAL_FUNCTION_DIRECTORY 
EXTERNAL_FUNCTION_DIRECTORY  "/opt/interbase/my_functions"

Действие

Этот параметр может быть использован в ibconfig несколько раз, для того, чтобы назначить местоположение для библиотек пользовательских функций (UDF). Если этот параметр отсутствует, то InterBase проверяет следующие каталоги: INTERBASE/UDF or $INTERBASE/intl. Этот параметр доступен только для варианта SuperServer.

Объяснение

InterBase ищет в заданных этим параметром каталогах библиотеки, которые он загружает по ссылке. Этот параметр позволяет задать любое число каталогов, в которых InterBase будет искать библиотеки пользовательских функций (UDF) или определения наборов символов (character set definitions).

Показания к изменению параметра

Если необходимо использовать большее число каталогов или другие каталоги, отличные от стандартных, то используйте этот параметр.
 

TCP REMOTE BUFFER

Параметры в ibconfig

TCP_REMOTE_BUFFER        8192

Действие

Этот параметр устанавливает максимальный размер пакетов TCP, используемых при обмене между клиентом и сервером. Возможны значения от 1448 до 32768 байт.

Объяснение

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

Показания к изменению параметра

Сильно загруженная сеть.
 
Этот документ был написан Анн Харрисон в октябре 2000 года, и авторские права на него принадлежат госпоже Харрисон и компании IBPhoenix Inc. Вы можете публиковать этот документ дословно, включая это замечание. Вы может обновлять его, исправлять и добавлять материал, но обязательно включать данное примечание о том, что исходная работа была проделана госпожой Харрисон и компанией IBPhoenix Inc.
 

Переведено – Алексей Ковязин, Алексей Карякин, 2002 год.
Консультанты – Дмитрий Кузьменко, Алексей Флегонтов.
Оригинал – https://www.ibphoenix.com/resources/documents/general/doc_55
 
Просьба присылать замечания по переводу данного документа по адресу akovjazin@devrace.com