Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil

Востриков С М

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

Рабочие станции

Требования к компьютерам-рабочим станциям, на которых исполняются клиентские части приложений базы данных на базе InterBase, определяются в основном требованиями ОС. Клиентская часть приложения базы данных InterBase не требует большего, чем обычные офисные программы. Клиентская же часть самого InterBase весьма легковесна, не требует много ресурсов и состоит всего из трех файлов (см. ниже главу "Состав модулей InterBase"). Можно с уверенностью

сказать, что большинству приложений баз данных InterBase будет более чем достаточно для выполнения компьютера офисного класса - например, Celeron с 256 Мбайт ОЗУ. Нижним пределом (для небольшого клиентского приложения) является компьютер класса Pentium-100 с 16 Мбайт ОЗУ.

Основные "рычаги" управления производительностью

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

Кеш базы данных

Кеш базы данных служит для хранения наиболее часто используемых страниц из базы данных. Его размер исчисляется в страницах и может быть установлен тремя разными способами:

* Заданием параметра файла конфигурации ibconfig DATABASE CASHE PAGES. При этом устанавливается значение кеша для каждой базы данных, обслуживаемой данным сервером; это означает, что для каждой подключенной базы данных будет распределен кеш указанного в данном параметре размера. Это не слишком гибкий способ, поэтому им обычно не пользуются, если компьютер-сервер обслуживает более одной базы данных. Этот параметр имеет следующие значения по умолчанию: InterBase 6 Classic (Linux) - 75, InterBase 6 SuperServer (Windows) - 2048, a InterBase 5.x - 256. Причем надо отметить, что для Classic устанавливается размер кеша для КАЖДОГО клиентского соединения.

* Установкой количества страниц для каждой индивидуальной базы данных с помощью инструмента gfix. Например, выполнение команды gfix -buffers 8192 для какой-либо базы данных приводит к тому, что все соединения к этой базе данных будут использовать кеш размером 8192 страницы. Помните, что версия Classic использует значение размера кеша для каждого клиентского соединения; поэтому не стоит устанавливать размер кеша в Classic более 2048 страниц (даже если у вас несколько гигабайтов ОЗУ). Необходимо отметить, что при создании базы данных задать размер кеша на уровне базы данных невозможно, - он устанавливается позже с помощью gfix.

* Установкой параметра функции InterBase API isc_dpb_num_buffers при соединении с базой данных.

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

Теперь о конкретных цифрах. Размер кеша может принимать значения от 50 до 65535 страниц. Чтобы посчитать, как много оперативной памяти потребует кеш базы данных, надо умножить размер страницы базы данных на размер кеша. Например, если страница имеет размер 8192 байта, а кеш имеет размер 5000 страниц, то потребуется 40960000 байт ОЗУ (около 40 Мбайт), чтобы вместить этот кеш. Несмотря на то что сейчас ОЗУ стоит достаточно дешево и экономить на нем не стоит, устанавливать размер кеша базы данных более 10000 страниц не следует, это вытекает из тестов, которые показывают уменьшение производительности InterBase при большом размере кеша. Помимо тестов, с результатами которых вы можете познакомиться на сайте www.ibase.ru. Ivan Prenosil указывает на малоизвестный факт: большой размер кеша заметно увеличивает время соединения с базой данной, и чем больше кеш, тем больше времени затрачивается на установку соединения. Правда, в Yaffil эта проблема решена.

Forced Writes

Forced Writes - это режим записи данных на диск. Существует два режима - синхронный и асинхронный, которым соответствуют значения Forced Writes ON и OFF. При асинхронном режиме записи

данных на диск (т. е. при FW OFF) данные пишутся в файловый кеш ОС, в результате чего ускоряются операции с ке- шированными данными. При синхронном режиме (FW ON) процесс, который изменяет данные, ожидает, пока они пишутся на диск, это позволяет помещать данные на диск гораздо надежнее, чем при асинхронной записи. Правда, стоит отметить, что обращения к диску производятся не после изменения каждой записи (это бы катастрофически снизило производительность), а в следующих случаях:

* когда происходит подтверждение транзакции: все страницы, затронутые изменениями в рамках этой транзакции, пишутся на диск;

* когда измененная страница становится "непопулярной": т. е. когда к ней перестают часто обращаться и нет смысла держать ее в кеше, она пишется на диск, а ее место в кеше занимает другая страница, к которой чаще обращаются;

* когда вытесняется несколько зависящих друг от друга страниц: запись одной из них на диск приводит к записи других;

* при исипользовании сервера InterBase с архитектурой Classic страница вытесняется из кеша одного пользователя и пишется на диск, если ее требует другой пользователь.

При включенном режиме асинхронного чтения данные пишутся на диск, когда этого пожелает ОС. При большом объеме ОЗУ база данных может почти целиком быть "втянута" в кеш. Тем не менее отключенный режим Forced Writes - это обоюдоострое оружие. Ускоряя операции чтения и записи данных, асинхронное чтение может привести к значительной потере данных в результате сбоя аппаратного или программного обеспечения. Квитированные данные могут находиться в кеше длительное время (часы и дни), поэтому сбой электропитания может привести к потере данных, являющихся результатом часов и даже дней работы. Поэтому стоит неоднократно подумать, прежде чем приносить надежность в жертву скорости и отключать Forced Writes. И конечно, не стоит включать режим асинхронной записи, если ваш сервер не оснащен источником бесперебойного питания.

Sweep Interval

Если посмотреть статистику по базе данных (как это сделать - см. в этой части главу "Статистика в InterBase"), то можно обнаружить в данных о заголовочной странице параметр Sweep interval. Этот параметр устанавливает разницу между старейшей интересующейся транзакцией (ОГГ) и следующей транзакцией (Next), при которой следует запускать процесс сборки "мусора". Подробнее о транзакциях и сборке "мусора" вы можете прочитать в главе, посвященной транзакциям (ч. 1), а с точки зрения производительности Sweep Interval интересует нас, поскольку при сборке "м>сора" работа обычных клиентов, работающих с базой данных, может замедлиться. Особенно это актуально для серверов, работающих в круглосуточном режиме Чтобы избежать проблем с производительностью, связанных с периодической сборкой "мусора", устанавливают Sweep Interval равным нулю, что означает запрет автоматической сборки "мусора". В этом случае процесс сборки "мусора" осуществляют вручную - например, с помощью резервного копирования. Дело в том, что процесс резервного копирования базы данных обычно сопровождается сборкой "мусора" (если не установлен флаг -garbage_collect). Полной заменой sweep процесс backup нельзя назвать, гак как во время sweeping происходит обновление статуса транзакций Поэтому если и отказываться от sweep, то необходимо заменить его не просто резервным копированием, а регулярным циклом backup/restore.

Чтобы установить sweep interval, используют инструмент gfix. Например, чтобы установить sweep interval в 0 и запретить автоматическую сборку "мусора", надо выполнить следующею команду:

gfix -h 0 -user SYSDBA -password <пароль> С:\database\myDatabase.gdb

Размер страницы базы данных

Ha производительность операций чтения и записи сильно влияет размер страницы базы данных. Если страница мала (менее 4096 байт), то серверу приходится многократно обращаться к диску, чтобы прочитать некоторый кусок данных, т. к. все операции производятся постранично. Если страница имеет большой размер (8192 или даже 16384 байта), то нужно меньше "дергать" диск для чтения и записи данных. Помимо этих очевидных соображений, от размера страницы также зависит глубина индексов базы данных' чем страница больше. тем глубина меньше и тем быстрее происходит поиск с использованием индексов (подробнее см. главу "Индексы" (ч. 1)).