Мир InterBase

Объяснение


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

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


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




В архитектуре Classic, когда один серверный процесс блокирует страницу базы данных или другой ресурс, который необходим второму процессу, второй процесс сигнализирует об этом первому. Чтобы сменить номер сигнала, используется данный параметр. Значение номера сигнала по умолчанию зависит от ОС:

NETWARE_386 BLOCKING_SIGNAL 101

WINDOWS_ONLY BLOCKING_SIGNAL 101 

All Others BLOCKING_SIGNAL SIGUSR1




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






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

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

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

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




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




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

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




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




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

Идентификатор типа блокировки

Английское наименование

Русский перевод наименования блокировки

#define LCK_none 0

Отсутствие блокировок

#define LCK_null 1

Existence

Блокировка существования объекта

#define LCK_SR 2

Shared Read

Совместное чтение

#define LCK_PR 3

Protected Read

Защищенное Чтение

#defme LCK_SW 4

Shared Write

Совместная запись

#define LCK_PW 5

Protected Write

Защищенная запись

#define LCK_EX 6

Exclusive

Эксклюзивная блокировка

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

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

none

null

Shared Read

Protected Read

Shared Write

Protected Write

Exclusive

попе

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), будут "топтаться" в очереди. Если загрузка базы данных очень велика, такое поведение может привести к тому, что соединения, которые требуют высоких уровней блокировок, могут ждать неопределенно долго, потому что новые читающие соединения (которые запрашивают низкие уровни блокировки) будут постоянно прибывать и "лезть без очереди".




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

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

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




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




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




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

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




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

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




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




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




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



Содержание раздела