EXTERNAL FUNCTION DIRECTORY.. 11
Параметры
в 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. События. Механизм оповещения о событиях основывается на
блокировках. Число событий и число клиентов, ожидающих этих событий, влияют на
размер таблицы блокировок.
Параметры
в 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",
тогда следует увеличить количество семафоров.
Параметры
в 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 нет никакой необходимости изменять этот
параметр.
Параметры
в ibconfig
V4_EVENT_MEM_SIZE
32768
ANY_EVENT_MEM_SIZE 32768
Действие
Параметр устанавливает начальный размер памяти, выделенной
для таблицы событий (events).
Объяснение
Таблица событий (event table) хранится в
отображенной (mapped)
памяти. В архитектуре Classic место под эту таблицу выделяется
для каждого клиентского соединения. В архитектуре SuperServer одна таблица совместно используется всеми клиентами.
Показания к изменению параметра
Таблица увеличивается динамически, поэтому вроде бы нет
причины для того, чтобы устанавливать этот параметр.
Параметры
в ibconfig
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, то
увеличение размера кэша может улучшить производительность.
Параметры
в 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).
Параметры
в 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) может улучшить
производительность.
Параметры
в ibconfig
SERVER_WORKING_SIZE_MIN 0
SERVER_WORKING_SIZE_MAX 0
Действие
Этот параметр устанавливает ограничения размера рабочей
физической памяти (working size), доступный SuperServer’у на платформе Windows/NT/2000. Параметр измеряется в
1-килобайтных блоках. По умолчанию, оба параметра имеют значение 0, что означает
– нет ограничений.
Объяснение
Ограничивая максимальный размер рабочей памяти, можно
заставить IB «упасть
замертво» раньше времени из-за недостатка памяти. Увеличивая минимальный размер
рабочей памяти, вы можете заставить
IB «захватывать» память
тогда, когда она ему не нужна.
Показания к изменению параметра
Установка минимального размера рабочей памяти может устранить
некоторые затраты на постепенное разрастание памяти сервера – то есть выделить
столько памяти, чтобы серверу не пришлось больше ее увеличивать и тратить на это
какие-то усилия. Установка максимального размера рабочей памяти может удержать
сервер от «пожирания» всей доступной памяти на системах с малым ее
количеством. Не запускайте InterBase
SuperServer на системах с малым
количеством памяти.
Параметры
в 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 был удален
из конфигурационного файла IB6.x, по крайней мере в SuperServer под NT. Однако исходный код
для того, чтобы прочитать и интерпретировать этот параметр все еще существует.
Параметры
в ibconfig
LOCK_HASH_SLOTS 101
Действие
Этот
параметр определяет ширину хэш-таблицы, которая используется для поиска блокировок. По умолчанию значение этого
параметра - 101. Число должно быть
простым, чтобы хэш-алгоритм производил хорошее
распределение. Он может быть в диапазоне от 101 до 2048.
Объяснение
Представьте себе, что хэш-таблица – это
одномерный массив с цепочками, которые «свисают» из каждой ячейки этого массива.
Менеджер блокировок хэширует имя объекта и затем
вычисляет остаток от целочисленного деления этой величины на число хэш-слотов в массиве – таким образом он определяет ячейку,
на которую надо «подвесить» блокировку данного объекта.
Когда менеджер блокировок ищет определенную блокировку, он
определяет ячейку хэш-массива аналогичным образом, а
затем спускается вниз по цепочке, «подвешенной» к данной ячейке, и ищет объект с
правильным именем. Если находится более одного объекта с этим именем, он
проходит по цепочке «однофамильцев», которая подвешивается к первому объекту,
который соответствует искомому имени.
OK,
got
that? Чем
длиннее будут цепочки, подвешенные к каждому слоту, тем медленнее будет работать
менеджер блокировок. В среднем каждая цепочка должна иметь не более 10 ячеек.
Показания к изменению параметра
Первым признаком для изменения этого параметра должна быть
общая низкая производительность системы с большим количеством пользователей и
страниц в кэше. Запустите инструмент iblockpr из директории %INTERBASE%\Bin для печати блокировок. Если средняя длина более 10,
увеличьте число хэш-слотов для этого параметра. Для
начала умножьте среднюю длину цепочек на текущее число слотов и поделите на 9, а
затем возьмите простое целое число, большее полученного значения (но меньшее
2048). Если вы производите подобную настройку на SuperServer’е, то необходимо также увеличить размер
таблицы блокировок.
Параметры
в 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, чтобы увидеть, как изменяется
производительность.
Параметры
в ibconfig
LOCK_ACQUIRE_SPINS 0
Действие
Для архитектуры SuperServer
этот параметр не производит никакого действия. В архитектуре Classic только один клиент
одновременно может обращаться к таблице блокировок. Доступ к таблице блокировок
определяется мьютексом. Запрос мьютекса может быть либо условным – когда задержка является
ошибкой и запрос должен быть
повторен, либо безусловным – когда запрос будет ожидать до тех пор, пока его не
обслужат. Параметр LOCK_ACQUIRE_SPINS устанавливает число попыток
выполнения условного запроса. По умолчанию – 0 (ноль).
Объяснение
Условный запрос мьютекса
повторяется определенное число раз, определяемое параметром LOCK_ACQUIRE_SPINS, а затем превращается в
безусловный запрос. Вроде бы это может принести пользу на машинах с несколькими
процессорами (SMP). Что
весьма сомнительно.
Показания к изменению параметра
Нет.
Параметры
в ibconfig
CONNECTION_TIMEOUT 180
Действие
Устанавливает
время ожидания (таймаут) соединения. По умолчанию – 180
секунд.
Объяснение
Чтобы распознать клиентов, которые некорректно разорвали
соединение, включая тех Windows-клиентов, которые выключили свои
компьютеры, не закрыв приложения, InterBase посылает фиктивный пакет в
течение времени ожидания (таймаута) соединения. Если ответа на запрос нет в
течение установленного времени, то InterBase разрывает
соединение.
Время ожидания также может быть указано в dpb (database parameter
block).
Соответствующий параметр имеет название isc_dpb_connect_timeout.
Показания к изменению параметра
Чем выше значение этого параметра, тем меньше фиктивных
запросов будут загружать сеть. С другой стороны, «мертвые» соединения будут
дольше «висеть». Рекомендуется значительно увеличить значение этого параметра,
если вы точно уверены, что клиентские приложения не будут некорректно завершать
свою работу.
Параметры
в ibconfig
DUMMY_PACKET_INTERVAL 60
Действие
Этот
параметр определяет, насколько
часто будут посылаться фиктивные запросы для проверки того, что клиент все еще
работает. По умолчанию это 60 секунд.
Объяснение
InterBase
закрывает соединение, когда клиент перестает отвечать. Для того, чтобы определить, что клиент
более не отвечает на запросы, IB ожидает некоторое время (определяемое
параметром CONNECTION_TIMEOUT), а затем посылает фиктивный
запрос для проверки соединения. Если при посылке возникает ошибка, то IB заключает, что клиент
«мертв».
Вы можете настроить частоту, с которой посылаются
фиктивные пакеты, либо с помощью этого конфигурационного параметра, либо
на уровне соединения – установив в структуре dpb параметр isc_dpb_dummy_packet_interval.
Показания
к
изменению
параметра
Чем выше это значение, тем реже фиктивные пакеты будут появляться с сети. Но, с другой стороны, «мертвые» соединения будут дольше «висеть». Рекомендуется значительно увеличить значение этого параметра, если вы точно уверены, что клиентские приложения не будут некорректно завершать свою работу.
Примечание
Есть непроверенная информация,
что значение 0 отключает посылку фиктивных пакетов.
Параметры
в ibconfig
TMP_DIRECTORY <size> <quoted directory
string>
TMP_DIRECTORY 20000 "/opt/interbase/tmp"
Действие
Этот параметр может использоваться в файле ibconfig несколько раз для того, чтобы
определить местоположение временных файлов IB. Размер временных файлов задается в
байтах. Если в ibconfig нет этого параметра, то
InterBase проверяет
следующие переменные окружения: INTERBASE_TMP, TMP, and TEMP.
Этот параметр доступен только для архитектуры SuperServer.
Объяснение
InterBase использует временные файлы для
разнообразных операций, особенно для хранения промежуточных результатов
сортировки. Этот конфигурационный параметр позволяет вам определять список
каталогов, которые будут использоваться для хранения временных файлов.
Повторение параметра позволяет добавлять дополнительные каталоги.
Показания к изменению параметра
Установка этого параметра позволяет назначить ряд временных
каталогов и точно определить количество места, которое будет использовано в
каждом из них.
Параметры
в ibconfig
EXTERNAL_FUNCTION_DIRECTORY <quoted directory
string>
EXTERNAL_FUNCTION_DIRECTORY "/opt/interbase/my_functions"
Действие
Этот параметр может быть использован в ibconfig несколько раз, для того,
чтобы назначить местоположение для библиотек пользовательских функций (UDF). Если этот параметр
отсутствует, то InterBase проверяет следующие каталоги:
INTERBASE/UDF or $INTERBASE/intl. Этот параметр доступен
только для варианта SuperServer.
Объяснение
InterBase ищет в заданных этим
параметром каталогах библиотеки, которые он загружает по ссылке. Этот параметр
позволяет задать любое число каталогов, в которых InterBase будет искать библиотеки
пользовательских функций (UDF) или определения наборов символов
(character set definitions).
Показания
к
изменению
параметра
Если необходимо использовать большее число каталогов или
другие каталоги, отличные от стандартных, то
используйте этот параметр.
Параметры
в ibconfig
TCP_REMOTE_BUFFER
8192
Действие
Этот параметр устанавливает максимальный размер пакетов TCP, используемых при обмене
между клиентом и сервером. Возможны значения от 1448 до 32768 байт.
Объяснение
InterBase производит упреждающее чтение
для клиента и может посылать несколько строк данных в одном пакете. Чем больше
размер пакета, тем больше данных пересылается за один раз.
Показания к изменению параметра
Сильно загруженная сеть.
Этот документ был написан Анн Харрисон в октябре 2000 года, и авторские права на него
принадлежат госпоже Харрисон и компании IBPhoenix, Inc. Вы можете публиковать этот документ
дословно, включая это замечание. Вы может обновлять его, исправлять и добавлять
материал, но обязательно включать данное примечание о том, что исходная работа
была проделана госпожой Харрисон и компанией IBPhoenix
Inc
Переведено – Алексей Ковязин, Алексей Карякин, 2002
год.
Консультанты – Дмитрий Кузьменко, Алексей
Флегонтов.
Оригинал - http://www.ibphoenix.com/ibp_config.html
Просьба присылать замечания по переводу данного документа по
адресу akovjazin@devrace.com