Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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

! ! !

ПРИМЕЧАНИЕ. Для запуска gfix вы должны быть пользователем SYSDBA или владельцем базы данных. Более подробную информацию об использовании gfix см. в главе 39.

. ! .

Использование инструмента запросов командной строки isql

У вас есть две возможности для увеличения количества страниц кэша в процессе одной сессии утилиты командной строки isql.

Первый вариант- включить количество страниц (n) как переключатель при запуске isql:

isql -с n имя-базы-данных

где n- количество используемых в сессии страниц кэша, которое временно перекрывает любое значение, установленное В DefaultDbCachePages (database_cache_pages) или в gfix. Должно быть больше 9.

В качестве альтернативы вы можете включить CACHE n В качестве аргумента оператора CONNECT при выполняющейся isql:

isql > connect имя-базы-данных CACHE n

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

Использование буфера параметров базы данных

В приложении размер кэша может быть установлен в буфере параметров базы данных (Database Parameter Buffer, DPB) с использованием параметра isc_dpb_num_buffers или isc_dpb_set_page_buf fers в соответствии с требованиями вашего сервера.

* isc_dpb_num_buffers - устанавливает количество буферов (страниц кэш-памяти), которое будет использоваться для текущего соединения. Это имеет особый смысл в архитектуре Классического сервера, где каждое соединение получает статически выделенную кэш-память. Для Суперсервера настоящий параметр установит количество буферов, используемых указанной базой данных, если эта база данных еще не открыта, однако это значение теряется после того, как сервер закрывает базу данных.

* isc_dpb_set_page_buffers - используется как в Классическом сервере, так и в Суперсервере. Этот параметр имеет тот же эффект, что и использование gfix для постоянного перекрытия DefaultDbCachePages.

! ! !

ВНИМАНИЕ! Будьте осторожны, предоставляя приложению конечного пользователя возможность модифицировать кэш. Хотя любой запрос на изменение размера кэша будет проигнорирован во всех запросах соединения, кроме первого, предоставление возможности изменения установок сервера пользователям, не являющимися техническими специалистами, может иметь непредсказуемые последствия для производительности и оказать воздействие на весь сервер.

. ! .

Изменение значений по умолчанию для сервера

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

Для изменения установок откройте файл конфигурации в текстовом редакторе и найдите нужный параметр:

* для версии 1.5 уберите комментарий у DefaultDbCachePages и измените число;

* для версии 1.0.x в файле конфигурации это defauit_cache_pages. Если необходимо, уберите комментарий В строке и создайте запись default_cache_pages=nnnn, где nnnn - новый размер кэша.

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

Прагматичный подход

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

Хороший совет: не бросайтесь оптимизировать размер кэша для Firebird по принципу "обязан сделать". В процессе разработки используйте установки по умолчанию, а при установке системы просто проверьте, подходит ли объем доступной памяти RAM значениям по умолчанию.

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

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

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