Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
Важно понимать, что каждая система имеет критическую точку, где слишком большой размер кэша будет потреблять больше памяти, чем может "предложить" система. За этой точкой увеличение кэша приведет к ухудшению производительности.
Ограничения и значения по умолчанию
Минимальный размер кэша- 50 страниц. Максимума не существует, пока выделяемый объем памяти не превышает доступный объем RAM.
Величиной выделяемого кэша по умолчанию является:
* Суперсервер. Для каждой выполняющейся базы данных 2048 страниц. Все пользователи
Для оценки используемых ресурсов: одна выполняющаяся база данных с установками по умолчанию для PAGE_SIZE (4 Кбайт) и DefauitDbcachePages (2 Кбайт) требует 8 Мбайт памяти. Две базы данных, выполняющиеся с теми же установками, требуют 16 Мбайт и т.д. Используемый объем кэша по умолчанию вычисляется следующим образом:
PAGE_SIZE * DefaultDbCachePages * количество баз данных
* Классический сервер. Для каждого клиентского соединения 75 страниц кэша. Каждое соединение выделяет свой собственный кэш. Объем требуемой памяти является суммой требований к кэшу всех клиентских соединений со всеми базами данных. Используемый объем кэша вычисляется следующим образом:
PAGE_SIZE * DefaultDbCachePages * количество соединений
Вычисление размера кэша
Когда Firebird читает страницу базы данных с диска, он сохраняет эту страницу в кэше. Обычно размер кэша по умолчанию является достаточным. Если ваше приложение использует соединения из пяти и более таблиц, Firebird Суперсервер может автоматически увеличить размер кэша, если текущего размера недостаточно. Если ваше приложение хорошо локализовано (т. е. постоянно использует одну и ту же небольшую часть базы данных), вы можете увеличить размер кэша так, что серверу никогда не понадобится удалять какую-либо страницу из кэша для помещения туда другой.
Поскольку DbCache сконфигурирован в страницах, очевидно, что база данных с большим размером страницы потребляет больше памяти, чем база данных с меньшим размером страницы. Когда множество баз данных выполняется на одном и том же сервере, может оказаться желательным переопределить размер кэша на стороне сервера значением на уровне базы данных или в некоторых случаях на уровне приложения.
Приложение, которое интенсивно выполняет индексированные выборки, требует больше буферов, чем приложение, преимущественно выполняющее добавление данных.
Там, где много клиентов обращается к различным таблицам или к различным частям одной таблицы, потребность в памяти выше, чем в случае, когда большинство клиентов работает с одними и теми же или частично перекрывающимися наборами данных.
Может случиться, что слишком много буферов кэша будет выделено из имеющейся RAM. При наличии большого количества одновременно выполняющихся баз данных запрос может затребовать больше RAM, чем доступно в системе. Кэш будет перекачиваться вперед и назад между RAM и диском, уничтожая преимущества кэширования. Другие приложения (включая сервер) будут испытывать недостаток в памяти, если кэш будет слишком велик.
Поэтому важно, чтобы в системе был установлен соответствующий объем RAM для обеспечения требований сервера баз данных к памяти. Если производительность базы данных важна для ваших пользователей, то исключите создание конкуренции
Оценка размера кэша не является простой или точной наукой, особенно если у вас множество баз данных, выполняющихся одновременно. Использование сервером кэша определяется базой данных с наибольшим размером страниц. Классический сервер выделяет кэш для каждого соединения, в то время как Суперсервер объединяет кэш для всех соединений одной базы данных. Как отправная точка, это будет полезным для работы с числами и нужно для базы данных с наибольшим размером страницы. Реальные условия использования определят, где требуются корректировки.
Нет необходимости иметь кэш, вмещающий всю базу данных. Найдите коэффициент уменьшения для каждой базы данных, оценивая ту часть, к которой, скорее всего, будет доступ в процессе обычного использования. Совет по оценке простой - не существует "правила". Пусть, когда мы говорим о "DbCachePage", мы имеем в виду размер кэша, но не обязательно при условии установок сервера по умолчанию для новых и неконфигурированных баз данных.
Коэффициент уменьшения r должен иметь значение между 0 и 1.
Размер базы данных в страницах может быть установлен следующим образом:
* для однофайловой базы данных возьмите максимально возможный в файловой системе размер файла минус 1 байт и разделите на размер страницы. Для операционных систем, поддерживающих очень большие файлы, используйте фактический размер файла базы данных вместо максимального размера файла;
* для многофайловой базы данных возьмите значение STARTING AT первого вторичного файла и прибавьте значения LENGTH всех вторичных файлов.
Пусть DbCachePage равен количеству страниц кэша, требуемых для этой базы данных.
Для каждой базы данных вычислите:
DbCachePages = r * размер
Вычислите и запишите это число для каждой базы данных.
! ! !
СОВЕТ. Храните эти записи в другой документации по базе данных для использования, при необходимости, в настройке кэша индивидуальной базы данных.
. ! .
Для вычисления требуемого объема RAM для кэша базы данных на вашем сервере возьмите значение PAGE SIZE для каждой базы данных и умножьте на значение DefaultDbCachePages. Просуммированные результаты для всех баз данных дадут приблизительные требования к минимальному объему RAM для кэширования баз данных.
Установка размера кэша на уровне базы данных
Существует несколько способов конфигурирования размера кэша для конкретной базы данных. Изменения не действуют до тех пор, пока не будет установлено новое соединение с Суперсервером Firebird или не будет соединен новый клиент с Классическим сервером.
Рекомендуемый способ установки значения на уровне базы данных для перекрытия значения DefaultDbCachePages - использование утилиты командной строки gfix со следующими переключателями: