EnОшибки конфигурирования баз СУБД Firebird
© kdv, iBase.ru, 27.08.2025, upd 24.09.2025.
Соавторы – Алексей Ковязин, Василий Сидоров, Павел Зотов
Что вообще за конфигурирование
Что такое «конфигурация» Firebird
Калькулятор конфигураций
Как редактировать файлы конфигурации firebird.conf и databases.conf
Главное правило в отношении памяти
firebird.conf
Кэш в заголовке базы данных
databases.conf
Задание параметров
Одна или несколько баз данных на сервере
Одна база на сервере
Две-три разных базы
Сто одинаковых баз
Загрузка измененных конфигов
Различие в кэшировании
Подробнее о кэшировании sort с FB 4.0
Кэш метаданных
FileSystemCacheThreshold
LockMemSize
Что не конфигурируется
Чего здесь нет
Чатботы и файлы конфигураций
Статьи и видео
Вплоть до Firebird 2.5 всё было достаточно просто. Вот есть аппаратное обеспечение (память, проц, диск), вот есть firebird.conf, в котором указаны все общие параметры для любых баз данных, открываемых на этом сервере.
Кроме того, ситуация упрощалась тем, что суперсервер Firebird 2.5 не масштабировался по ядрам (просто не распараллеливался для конкретной БД), и повсеместно использовалась архитектура Classic, или максимум SuperClassic (в которой был только общий параметр памяти сортировки). В результате конфигурирование было однотипным, рассчитанным на архитектуру именно Classic.
Начиная с Firebird 3.0 конфигурирование разделилось на две части
Дополнительно, в Firebird 3.0 появилась масштабируемая архитектура SuperServer, которая распараллеливается по ядрам, и при переходе с Classic 2.5 компании массово начали использовать SuperServer 3.0. А конфигурирование для Classic и SuperServer разное, а уж для 2.5 и 3.0 – тем более.
В итоге, получается, что нам при переходе с 2.5 на 3.0 и далее нужно не только менять архитектуру Firebird, но и еще и модифицировать конфигурацию для оптимальной производительности. Кроме того, в 2.5 для Classic и SuperServer почти не было вариантов конфигурирования для разных баз данных.
Сейчас благодаря новым возможностям 3.0 возникают разные ситуации. Самая примитивная, когда на сервере только одна база данных. И более сложные, которые происходят когда на сервере две базы данных или более.
Так что, дальше вся информация будет относиться только к версиям Firebird 3.0, 4.0, 5.0.
По конфигурированию версий включительно до 2.5 и так уже есть достаточно информации в сети (см. финальный раздел «Видео и ссылки»).
Внимание! Эта статья вовсе не справочная по параметрам конфигурации Firebird. Она только о проблемах, которые могут поджидать при некорректном изменении параметров.
По умолчанию для 3.0 и выше нормальный режим это SuperServer, т.е. общий кэш БД для всех пользователей, которые к ней обращаются.
В базовом firebird.conf находится подробное описание всех параметров, и сами параметры с их умолчательным значением в закомментированном виде – предваряемые символом # (диез, шарп, решетка и т.д.)
Чтобы изменить параметр, достаточно убрать символ комментария #, и изменить значение параметра. После сохранения firebird.conf нужно рестартовать сервис Firebird (см. далее).
https://cc.ib-aid.com/
Вы задаете версию Firebird, архитектуру сервера, количество памяти, пользователей и ядер процессора, размер страницы базы данных, и т.д., и получаете готовые файлы конфигурации.
! в любом случае рекомендуется сохранить оригинальные firebird.conf и databases.conf, т.к. там хранится подробное описание параметров и их умолчательные значения.
Если есть сомнения, или непонятно, что вам выдал конфигуратор – обращайтесь к нам (support@ibase.ru). У нас есть ряд услуг, которые помогут вам получить максимально возможную производительность от сервера - https://www.ibase.ru/techsupp/ .
Вообще лучше оставить базовый firebird.conf, и переименовать его в нечто вроде firebird_orig.conf, чтобы при необходимости смотреть в нём описания параметров и их умолчательные значения. Затем создать новый firebird.conf, и записать туда только измененные параметры.
Также, крайне желательно комментировать изменения параметров, которые могут происходить время от времени.
Например,
#2025-05-12, Firebird 3.0 super, увеличено ОЗУ, переконфигурировано kdv
Т.е. когда, в каком виде, в результате чего, и кем сделано.
Firebird никогда не будет аллокировать больше памяти, чем ему задано, поэтому – да, он может нормально работать на системах с 4гб памяти. Но сейчас на промышленных системах с сотнями и тысячами пользователей такие настройки никуда не годятся.
Поэтому, нужно увеличивать и размер кэша, и размер памяти сортировок, и размер памяти блокировок.
Вопрос – до какого уровня. И ответ вполне известен. Базово операционные системы (и Windows и Linux) предполагают, что память между приложениями и кэшем ОС будут распределены примерно как 50/50. 50% будут использованы под приложения (и их внутренний кэш, и прочее), а 50% - под остальные нужды файловой системы – файловый кэш, и прочее.
Поэтому, когда вы решите менять параметры в firebird.conf и databases.conf, нужно помнить что вам доступно примерно 50-60% физической памяти. В противном случае во время работы ОС начнет выгружать Firebird в виртуальную память, и в определенные моменты производительность станет только хуже.
(разумеется, вам доступно менее 50% памяти ОС, если у вас на этом же сервере работают другие приложения, такие как терминальный сервер, другие СУБД, и прочее).
В общем, запомните, что нормально выделить для Firebird не более 50-60% от памяти операционной системы. И сюда входит – кэш всех баз данных, память сортировки, память менеджера блокировок, и память кэша метаданных.
Можно также взять параметры от калькулятора конфигураций, а затем пробовать увеличивать кэш (и память сортировок, если они есть) где-то на 10% в неделю. Как только начнется выгрузка в своп – вернуться к предыдущим значениям.
В firebird.conf начиная с firebird 3 все параметры, которые можно задавать для конкретной базы данных (в databases.conf) маркируются как
# Per-database configurable.
Если у какого-то параметра нет такого комментария, это значит, что параметр действует только на сервер целиком.
firebird.conf при изменениях перечитывается в зависимости от архитектур:
- Classic/SuperClassic – для каждого нового коннекта к любой БД на этом сервере
- SuperServer – только после остановки и старта службы Firebird (или приложения)
Тут нужно понимать, что часть параметров относятся целиком к серверу, а часть параметров – к базе данных.
Например, параметр
#DefaultDbCachePages = 2048
задает размер кэша по умолчанию для каждой открываемой БД на сервере. Если эта БД одна, будет выделена память в 2048 страниц. Если баз открыто две, то под кэш уже будет выделено раздельно два раза по 2048 страниц. И так далее. Общего кэша для всех открытых баз нет.
Для полного понимания, какие параметры относятся к серверу целиком, а какие только к конкретной базе данных, нужно смотреть на параметры, доступные для конфигурирования в databases.conf (например, те параметры, которые недоступны для databases.conf, относятся только к серверу).
Однако есть один параметр – Page buffers, который соответствует параметру DefaultDbCachePages.
Если этот параметр задан в заголовке БД, то он является приоритетным.
Собственно, до Firebird 3.0 это был единственный способ задания раздельного размера кэша для конкретной базы данных на одном сервере.
Однако, о приоритете этого параметра часто забывают, и он на самом деле вреден. Потому что для Classic и SuperServer размер кэша БД должен быть разным. Также могут быть проблемы при переносе такой базы данных с одного сервера на другой (с разным размером памяти системы), и так далее.
Рекомендуем обнулить этот параметр, чтобы размер кэша БД определялся через firebird.conf и databases.conf.
Для начала нужно проверить состояние параметра Page buffers командой
gstat –h database
и если page buffers не 0, обнулить его
gfix –b 0 database …
# Example Database:
#
employee.fdb = $(dir_sampleDb)/employee.fdb
employee = $(dir_sampleDb)/employee.fdb
#
# Master security database specific setup.
# Do not remove it until you understand well what are you doing!
#
security.db = $(dir_secDb)/security3.fdb
{
RemoteAccess = false
DefaultDbCachePages = 50
}
Здесь задаются параметры конфигурации, отмеченные как
# Per-database configurable
в firebird.conf (за описанием конкретного параметра обращайтесь в firebird.conf)
Их достаточно много, вот список
Firebird 3.0
#RemoteAccess = true
#ExternalFileAccess = None
#DefaultDbCachePages = 2048
#DatabaseGrowthIncrement = 128M
#FileSystemCacheThreshold = 64K
#AuthServer = Srp (см. подробнее в firebird.conf)
#UserManager = Srp (см. подробнее в firebird.conf)
#AllowEncryptedSecurityDatabase = false
#Providers = Remote,Engine12,Loopback
#DeadlockTimeout = 10
#MaxUnflushedWrites = 100
#MaxUnflushedWriteTime = 5
#ClearGTTAtRetaining = 1
#LockMemSize = 1M
#LockAcquireSpins = 0
#LockHashSlots = 8191
#EventMemSize = 64K
#GCPolicy = combined
#SecurityDatabase = $(dir_secDb)/security3.fdb
Firebird 4.0, новые и измененные по умолчанию
#TempTableDirectory =
#UseFileSystemCache = true
#TempCacheLimit = 64M
#MaxIdentifierByteLength = 252
#MaxIdentifierCharLength = 63
#InlineSortThreshold = 1000
#AuthServer = Srp256
#Providers = Remote,Engine13,Loopback
#StatementTimeout = 0
#ConnectionIdleTimeout = 0
#OnDisconnectTriggerTimeout = 180
#ClearGTTAtRetaining = 0
#DataTypeCompatibility =
#SnapshotsMemSize = 64K
#TipCacheBlockSize = 4M
#SecurityDatabase = $(dir_secDb)/security4.fdb
Обратите внимание, что с Firebird 4.0 кэш сортировок (#TempCacheLimit = 64M) теперь не общий для всех баз сервера, а отдельный для каждой базы, даже если это параметр не задан в databases.conf. Так что для двух баз начиная с 4.0 размер памяти сортировок будет по умолчанию 64М * 2.
Кроме того, появился параметр DataTypeCompatibility, который может принимать значения 2.5 и 3.0, это сделано специально, чтобы обеспечить совместимость приложений, которые раньше работали с версиями 2.5 и 3.0, и не понимают новых типов данных, появившихся в версиях 4.0 и выше. Если есть только «старые» приложения, то лучше всего этот параметр устанавливать именно в firebird.conf для всех БД на этом сервере.
Firebird 5.0, новые и измененные по умолчанию
#OptimizeForFirstRows = false
#OuterJoinConversion = true
#SubQueryConversion = false
#DefaultProfilerPlugin = Default_Profiler
#ConnectionIdleTimeout = 0
#RemoteAuxPort = 0
#MaxStatementCacheSize = 2M
#SecurityDatabase = $(dir_secDb)/security5.fdb
! в зависимости от запросов в конкретной системе может потребоваться переключение OuterJoinConversion = false, если некоторые запросы внезапно начали «тормозить». Опять же, сделать это лучше для сервера целиком, в firebird.conf.
В минимальном варианте databases.conf соответствует старому функционалу. Например, добавляем строки
baza=c:\data\baza.fdb
baza_test=c:\data\baza_test.fdb
В результате клиентские приложения могут использовать строку коннекта вместо
server:c:\data\baza.fdb
строку
server:baza
И если базы перемещаются с места на место, то достаточно переместить файл БД и изменить путь псевдонима в databases.conf – клиентские приложения не нужно будет переконфигурировать.
Чтобы теперь задать конкретные параметры для базы данных (которые вы уже видели выше) нужно после строки псевдонима дописать эти параметры, обрамленные фигурными кавычками. Проще всего посмотреть на пример security.fdb, который есть в databases.conf
security.db = $(dir_secDb)/security4.fdb
{
RemoteAccess = false
DefaultDbCachePages = 256
}
Однако, при редактировании этой информации могут подстерегать неожиданности.
Например, не рекомендуется начальную фигурную скобку помещать в конце строки алиаса:
security.db = $(dir_secDb)/security4.fdb { # комментарий
будет воспринято как имя файла с фигурной скобкой. То есть, комментарий с # допустим либо только к значениям параметров в следующих строках, либо после блока фигурных кавычек.
Другой пример блока:
baza1 = c:\data\baza1.fdb
baza2 = c:\data\baza2.fdb
{
DefaultDbCachePages = 50000
}
Здесь для baza1 будут использованы значения, заданные в firebird.conf. а для baza2 – значение DefaultDbCachePages, указанное после алиаса baza2.
Частая ошибка, когда думают, что блок изменяемых параметров относится ко всем перечисленным алиасам до блока параметров в фигурных скобках.
Нет. Блок параметров в фигурных скобках должен быть указан для каждого алиаса, если для него требуются параметры, отличные от firebird.conf.
security.fdb обычно имеет крайне малый размер, и даже если ей задать огромный кэш, больше размера этого файла аллокировать кэш Firebird не станет. Но на всякий случай там всё равно указан размер кэша в 50 страниц, чего для базы аутентификации вполне достаточно даже для 1000 пользователей (хотя, в зависимости от частоты коннектов-дисконнектов размер кэша для security.fdb можно увеличить и до 250 страниц, и может быть более). Другие параметры для security.fdb вряд ли имеет смысл использовать.
примечание: в некоторых системах с большим количеством неизменяемых пользователей иногда ускорить аутентификацию помогает переключение security.fdb из режима read-write в режим read-only (gfix security…fdb –mode read_only. Однако, понятно, для добавления-удаления-модификации пользователей придется временно переводить такую базу в режим read-write
И если есть какие-то «выделяющиеся» базы, то тогда – да, только их прописать в databases.conf.
databases.conf – считывается при первом коннекте к БД (до отключения всех коннектов для SuperServer).
Таким образом, при изменении firebird.conf нужно рестартовать сервер Firebird, а при изменении databases.conf нужно убедиться, что все пользователи отключены от базы. Например, сделать gfix database –shut full –force 0, и затем gfix database –online.
Впрочем, для перечитывания databases.conf сделать рестарт Firebird не возбраняется.
#TempCacheLimit = 64M
определял общий размер памяти для сортировок, в Classic на коннект, в SuperClassic (с 2.5) и SuperServer – для процесса.
Причем, память эта распределяется только по мере выполнения запросов, которые требуют сортировки результата в памяти (если выделенной памяти не хватит, сортировка продолжится на диске).
Начиная с Firebird 4 этот параметр теперь для каждой базы данных отдельный.
То есть, если этот параметр, как прежде, указан у вас только в firebird.conf, то для SuperClassic/SuperServer в 4.0 этот размер кэша будет выделяться не как общий для всех баз данных, а отдельно для каждой базы на этом сервере, к которой будут коннекты (разумеется, как было сказано выше, только при выполнении запросов с сортировкой результата).
Например, на сервере была одна база, на сортировки было задано 10 гиг в firebird.conf, появилась вторая база, и на сортировки теперь стало выделяться 2 раза по 10 гиг.
Поэтому, данный параметр с 4.0 стал Per database configurable, и его нужно регулировать уже в databases.conf для конкретной базы данных.
А в firebird.conf этот параметр можно оставить по умолчанию.
Как определить размер кэша метаданных, хотя бы приблизительно?
Это можно сделать запросом, изложенным в статье
https://www.ibase.ru/db_meta_size
Например, по умолчанию
FileSystemCacheThreshold = 64K
и если DefaultDbCachePages будет выше этого значения (в страницах БД), то файловый кэш ОС для базы данных отключится.
Поскольку работа кэша Firebird и операционной системы сильно отличается, то в результате будет сильное падение производительности ввода вывода. Подробнее можно почитать в статье (https://www.ibase.ru/files/articles/performance/Firebird%20Optimizer%20-%20ORDER%20vs%20SORT.pdf со стр. 10 ). Если в двух словах, то производительность работы с БД упадет примерно в 19 раз.
В Firebird 4 был введен параметр
UseFileSystemCache = true
который заставляет сервер игнорировать FileSystemCacheThreshold в случае true (т.е. по умолчанию), и учитывать в случае false.
Поскольку UseFileSystemCache по умолчанию включен, беспокоиться не о чем. Однако, если он выключен, и хочется оставить работу файлового кэша ОС, рекомендуется заранее (на всякий случай) выставить FileSystemCacheThreshold куда больше чем DefaultDbCachePages.
Например, если у вас
DefaultDbCachePages = 100000
не надо экономить и ставить
FileSystemCacheThreshold = 110000
Поставьте FileSystemCacheThreshold сразу в 2-3 раза больше (или десять), тогда вы не будете удивлены плохой производительности, если поставите на сервер больше памяти, и переконфигурируете DefaultDbCachePages например до 150000 страниц.
Напомню, что все эти параметры также регулируются для конкретной базы данных в databases.conf.
Интересный момент – FileSystemCacheThreshold начиная с 3.0 – раздельный для баз данных. Т.е. в databases.conf одной можно выключить файловый кэш БД, а другой – включить (если с 4.0 и выше выключить UseFileSystemCache в firebird.conf. Но такие эксперименты крайне сомнительные. Даже для микроскопической security.fdb лучше файловый кэш ОС не выключать.
Тогда была магическая формула для вычисления оптимального значения, поскольку этот кусок памяти перераспределялся при исчерпании, в результате чего в работе пользователей могла возникнуть пауза от одной секунды до нескольких секунд (из-за аллокирования нового большего куска памяти и копирования всех данных из старого в новый).
LockMemSize >= Cache_pages * max_connections_count * 100
Однако, для SuperServer и версий 3.0 и выше эта формула уже не работает, и нужно смотреть в вывод fb_lock_print при максимальном количестве пользователей
D:\Firebird5>fb_lock_print -d e.fdb
LOCK_HEADER BLOCK
Version: 19, Creation timestamp: 2025-09-17 13:33:22
Active owner: 0, Length: 1048576, Used: 92668
…
Смотрим на Length, увеличиваем на 10-20%, выставляем это значение LockMemSize в firebird.conf, и всё.
Он раздельный для коннектов для SuperServer начиная с 3.0, и так же в 4.0 и 5.0.
Поначалу шли нормальные параметры, правда значения были подобраны несколько странно, а потом в тексте пошли абсолютно вымышленные имена параметров со значениями «с потолка».
Оказалось, что такой файл конфигурации сгенерировал чатбот (т.е. ChatGPT или какая-то другая нейросеть). Видимо, он галлюцинировал, а также взял часть параметров из конфигураций других СУБД.
Я даже не буду приводить пример таких параметров, чтобы на них не было ссылок в эту статью.
Но вот такое использовать категорически не надо.
Пользуйтесь человеческим калькулятором конфигураций https://cc.ib-aid.com/, который подбирает параметры не с потолка, а по нашему многолетнему опыту. Или читайте статьи, экспериментируйте, приобретайте опыт и конфигурируйте Firebird самостоятельно.
Или обращайтесь к нам за технической поддержкой - https://www.ibase.ru/techsupp/ .
Вопросы? support@ibase.ru.
Соавторы – Алексей Ковязин, Василий Сидоров, Павел Зотов
Прежде всего я купил несколько книг по птицеводству,
предполагая найти в них на первых страницах
нужные мне указания.
Ярослав Гашек, «Как я варил яйца всмятку», 1912
Оглавлениепредполагая найти в них на первых страницах
нужные мне указания.
Ярослав Гашек, «Как я варил яйца всмятку», 1912
Что вообще за конфигурирование
Что такое «конфигурация» Firebird
Калькулятор конфигураций
Как редактировать файлы конфигурации firebird.conf и databases.conf
Главное правило в отношении памяти
firebird.conf
Кэш в заголовке базы данных
databases.conf
Задание параметров
Одна или несколько баз данных на сервере
Одна база на сервере
Две-три разных базы
Сто одинаковых баз
Загрузка измененных конфигов
Различие в кэшировании
Подробнее о кэшировании sort с FB 4.0
Кэш метаданных
FileSystemCacheThreshold
LockMemSize
Что не конфигурируется
Чего здесь нет
Чатботы и файлы конфигураций
Статьи и видео
Что вообще за конфигурирование
И почему тут могут быть ошибки.Вплоть до Firebird 2.5 всё было достаточно просто. Вот есть аппаратное обеспечение (память, проц, диск), вот есть firebird.conf, в котором указаны все общие параметры для любых баз данных, открываемых на этом сервере.
Кроме того, ситуация упрощалась тем, что суперсервер Firebird 2.5 не масштабировался по ядрам (просто не распараллеливался для конкретной БД), и повсеместно использовалась архитектура Classic, или максимум SuperClassic (в которой был только общий параметр памяти сортировки). В результате конфигурирование было однотипным, рассчитанным на архитектуру именно Classic.
Начиная с Firebird 3.0 конфигурирование разделилось на две части
- firebird.conf - конфигурация общих параметров сервера и баз данных
- databases.conf - конфигурация конкретных параметров конкретной базы данных
Дополнительно, в Firebird 3.0 появилась масштабируемая архитектура SuperServer, которая распараллеливается по ядрам, и при переходе с Classic 2.5 компании массово начали использовать SuperServer 3.0. А конфигурирование для Classic и SuperServer разное, а уж для 2.5 и 3.0 – тем более.
В итоге, получается, что нам при переходе с 2.5 на 3.0 и далее нужно не только менять архитектуру Firebird, но и еще и модифицировать конфигурацию для оптимальной производительности. Кроме того, в 2.5 для Classic и SuperServer почти не было вариантов конфигурирования для разных баз данных.
Сейчас благодаря новым возможностям 3.0 возникают разные ситуации. Самая примитивная, когда на сервере только одна база данных. И более сложные, которые происходят когда на сервере две базы данных или более.
Так что, дальше вся информация будет относиться только к версиям Firebird 3.0, 4.0, 5.0.
По конфигурированию версий включительно до 2.5 и так уже есть достаточно информации в сети (см. финальный раздел «Видео и ссылки»).
Внимание! Эта статья вовсе не справочная по параметрам конфигурации Firebird. Она только о проблемах, которые могут поджидать при некорректном изменении параметров.
Что такое «конфигурация Firebird»
СУБД Firebird при старте ищет рядом со своим расположением файл firebird.conf, оттуда считывает параметры, если они изменены, и начинает работать в заданном режиме. Если не изменены – используются значения параметров по умолчанию.По умолчанию для 3.0 и выше нормальный режим это SuperServer, т.е. общий кэш БД для всех пользователей, которые к ней обращаются.
В базовом firebird.conf находится подробное описание всех параметров, и сами параметры с их умолчательным значением в закомментированном виде – предваряемые символом # (диез, шарп, решетка и т.д.)
Чтобы изменить параметр, достаточно убрать символ комментария #, и изменить значение параметра. После сохранения firebird.conf нужно рестартовать сервис Firebird (см. далее).
Калькулятор конфигураций
Мы сделали для вас калькулятор конфигураций, который позволяет при указании характеристик аппаратного обеспечения и количества пользователей получить наиболее оптимальные параметры для firebird.conf и databases.conf :https://cc.ib-aid.com/
Вы задаете версию Firebird, архитектуру сервера, количество памяти, пользователей и ядер процессора, размер страницы базы данных, и т.д., и получаете готовые файлы конфигурации.
! в любом случае рекомендуется сохранить оригинальные firebird.conf и databases.conf, т.к. там хранится подробное описание параметров и их умолчательные значения.
Если есть сомнения, или непонятно, что вам выдал конфигуратор – обращайтесь к нам (support@ibase.ru). У нас есть ряд услуг, которые помогут вам получить максимально возможную производительность от сервера - https://www.ibase.ru/techsupp/ .
Как редактировать файлы конфигурации firebird.conf и databases.conf
Что категорически не нужно делать, так это править параметры «по месту», т.е. раскомментировать и изменять умолчательные значения параметров.Вообще лучше оставить базовый firebird.conf, и переименовать его в нечто вроде firebird_orig.conf, чтобы при необходимости смотреть в нём описания параметров и их умолчательные значения. Затем создать новый firebird.conf, и записать туда только измененные параметры.
Также, крайне желательно комментировать изменения параметров, которые могут происходить время от времени.
Например,
#2025-05-12, Firebird 3.0 super, увеличено ОЗУ, переконфигурировано kdv
Т.е. когда, в каком виде, в результате чего, и кем сделано.
Главное правило в отношении памяти
По умолчанию Firebird потребляет крайне мало памяти, и это может быть причиной низкой производительности. Масса параметров firebird.conf были придуманы 40 лет назад, и как-то поправлены 25 лет назад. Например, умолчательный размер кэша БД в 2048 страниц при размере страницы 16к составляет всего 32 мегабайта. На фоне нынешних систем это микроскопическая величина.Firebird никогда не будет аллокировать больше памяти, чем ему задано, поэтому – да, он может нормально работать на системах с 4гб памяти. Но сейчас на промышленных системах с сотнями и тысячами пользователей такие настройки никуда не годятся.
Поэтому, нужно увеличивать и размер кэша, и размер памяти сортировок, и размер памяти блокировок.
Вопрос – до какого уровня. И ответ вполне известен. Базово операционные системы (и Windows и Linux) предполагают, что память между приложениями и кэшем ОС будут распределены примерно как 50/50. 50% будут использованы под приложения (и их внутренний кэш, и прочее), а 50% - под остальные нужды файловой системы – файловый кэш, и прочее.
Поэтому, когда вы решите менять параметры в firebird.conf и databases.conf, нужно помнить что вам доступно примерно 50-60% физической памяти. В противном случае во время работы ОС начнет выгружать Firebird в виртуальную память, и в определенные моменты производительность станет только хуже.
(разумеется, вам доступно менее 50% памяти ОС, если у вас на этом же сервере работают другие приложения, такие как терминальный сервер, другие СУБД, и прочее).
В общем, запомните, что нормально выделить для Firebird не более 50-60% от памяти операционной системы. И сюда входит – кэш всех баз данных, память сортировки, память менеджера блокировок, и память кэша метаданных.
Можно также взять параметры от калькулятора конфигураций, а затем пробовать увеличивать кэш (и память сортировок, если они есть) где-то на 10% в неделю. Как только начнется выгрузка в своп – вернуться к предыдущим значениям.
firebird.conf.conf
Это общие параметры сервера, которые имеют значения для всех баз, которые открываются на этом сервере.В firebird.conf начиная с firebird 3 все параметры, которые можно задавать для конкретной базы данных (в databases.conf) маркируются как
# Per-database configurable.
Если у какого-то параметра нет такого комментария, это значит, что параметр действует только на сервер целиком.
firebird.conf при изменениях перечитывается в зависимости от архитектур:
- Classic/SuperClassic – для каждого нового коннекта к любой БД на этом сервере
- SuperServer – только после остановки и старта службы Firebird (или приложения)
Тут нужно понимать, что часть параметров относятся целиком к серверу, а часть параметров – к базе данных.
Например, параметр
#DefaultDbCachePages = 2048
задает размер кэша по умолчанию для каждой открываемой БД на сервере. Если эта БД одна, будет выделена память в 2048 страниц. Если баз открыто две, то под кэш уже будет выделено раздельно два раза по 2048 страниц. И так далее. Общего кэша для всех открытых баз нет.
Для полного понимания, какие параметры относятся к серверу целиком, а какие только к конкретной базе данных, нужно смотреть на параметры, доступные для конфигурирования в databases.conf (например, те параметры, которые недоступны для databases.conf, относятся только к серверу).
Кэш в заголовке базы данных
Заголовок файла базы данных содержит некоторое количество параметров, которые относятся только к этой базе данных и не конфигурируются через firebird.conf и databases.conf. Это размер страницы базы данных и sweep interval.Однако есть один параметр – Page buffers, который соответствует параметру DefaultDbCachePages.
Если этот параметр задан в заголовке БД, то он является приоритетным.
Собственно, до Firebird 3.0 это был единственный способ задания раздельного размера кэша для конкретной базы данных на одном сервере.
Однако, о приоритете этого параметра часто забывают, и он на самом деле вреден. Потому что для Classic и SuperServer размер кэша БД должен быть разным. Также могут быть проблемы при переносе такой базы данных с одного сервера на другой (с разным размером памяти системы), и так далее.
Рекомендуем обнулить этот параметр, чтобы размер кэша БД определялся через firebird.conf и databases.conf.
Для начала нужно проверить состояние параметра Page buffers командой
gstat –h database
и если page buffers не 0, обнулить его
gfix –b 0 database …
databases.conf
По умолчанию содержимое databases.conf выглядит так# Example Database:
#
employee.fdb = $(dir_sampleDb)/employee.fdb
employee = $(dir_sampleDb)/employee.fdb
#
# Master security database specific setup.
# Do not remove it until you understand well what are you doing!
#
security.db = $(dir_secDb)/security3.fdb
{
RemoteAccess = false
DefaultDbCachePages = 50
}
Здесь задаются параметры конфигурации, отмеченные как
# Per-database configurable
в firebird.conf (за описанием конкретного параметра обращайтесь в firebird.conf)
Их достаточно много, вот список
Firebird 3.0
#RemoteAccess = true
#ExternalFileAccess = None
#DefaultDbCachePages = 2048
#DatabaseGrowthIncrement = 128M
#FileSystemCacheThreshold = 64K
#AuthServer = Srp (см. подробнее в firebird.conf)
#UserManager = Srp (см. подробнее в firebird.conf)
#AllowEncryptedSecurityDatabase = false
#Providers = Remote,Engine12,Loopback
#DeadlockTimeout = 10
#MaxUnflushedWrites = 100
#MaxUnflushedWriteTime = 5
#ClearGTTAtRetaining = 1
#LockMemSize = 1M
#LockAcquireSpins = 0
#LockHashSlots = 8191
#EventMemSize = 64K
#GCPolicy = combined
#SecurityDatabase = $(dir_secDb)/security3.fdb
Firebird 4.0, новые и измененные по умолчанию
#TempTableDirectory =
#UseFileSystemCache = true
#TempCacheLimit = 64M
#MaxIdentifierByteLength = 252
#MaxIdentifierCharLength = 63
#InlineSortThreshold = 1000
#AuthServer = Srp256
#Providers = Remote,Engine13,Loopback
#StatementTimeout = 0
#ConnectionIdleTimeout = 0
#OnDisconnectTriggerTimeout = 180
#ClearGTTAtRetaining = 0
#DataTypeCompatibility =
#SnapshotsMemSize = 64K
#TipCacheBlockSize = 4M
#SecurityDatabase = $(dir_secDb)/security4.fdb
Обратите внимание, что с Firebird 4.0 кэш сортировок (#TempCacheLimit = 64M) теперь не общий для всех баз сервера, а отдельный для каждой базы, даже если это параметр не задан в databases.conf. Так что для двух баз начиная с 4.0 размер памяти сортировок будет по умолчанию 64М * 2.
Кроме того, появился параметр DataTypeCompatibility, который может принимать значения 2.5 и 3.0, это сделано специально, чтобы обеспечить совместимость приложений, которые раньше работали с версиями 2.5 и 3.0, и не понимают новых типов данных, появившихся в версиях 4.0 и выше. Если есть только «старые» приложения, то лучше всего этот параметр устанавливать именно в firebird.conf для всех БД на этом сервере.
Firebird 5.0, новые и измененные по умолчанию
#OptimizeForFirstRows = false
#OuterJoinConversion = true
#SubQueryConversion = false
#DefaultProfilerPlugin = Default_Profiler
#ConnectionIdleTimeout = 0
#RemoteAuxPort = 0
#MaxStatementCacheSize = 2M
#SecurityDatabase = $(dir_secDb)/security5.fdb
! в зависимости от запросов в конкретной системе может потребоваться переключение OuterJoinConversion = false, если некоторые запросы внезапно начали «тормозить». Опять же, сделать это лучше для сервера целиком, в firebird.conf.
Задание параметров
До databases.conf был файл конфигурации псевдонимов (алиасов) aliases.conf, в котором просто задавался псевдоним БД и ее полный путь, и больше ничего.В минимальном варианте databases.conf соответствует старому функционалу. Например, добавляем строки
baza=c:\data\baza.fdb
baza_test=c:\data\baza_test.fdb
В результате клиентские приложения могут использовать строку коннекта вместо
server:c:\data\baza.fdb
строку
server:baza
И если базы перемещаются с места на место, то достаточно переместить файл БД и изменить путь псевдонима в databases.conf – клиентские приложения не нужно будет переконфигурировать.
Чтобы теперь задать конкретные параметры для базы данных (которые вы уже видели выше) нужно после строки псевдонима дописать эти параметры, обрамленные фигурными кавычками. Проще всего посмотреть на пример security.fdb, который есть в databases.conf
security.db = $(dir_secDb)/security4.fdb
{
RemoteAccess = false
DefaultDbCachePages = 256
}
Однако, при редактировании этой информации могут подстерегать неожиданности.
Например, не рекомендуется начальную фигурную скобку помещать в конце строки алиаса:
security.db = $(dir_secDb)/security4.fdb { # комментарий
будет воспринято как имя файла с фигурной скобкой. То есть, комментарий с # допустим либо только к значениям параметров в следующих строках, либо после блока фигурных кавычек.
Другой пример блока:
baza1 = c:\data\baza1.fdb
baza2 = c:\data\baza2.fdb
{
DefaultDbCachePages = 50000
}
Здесь для baza1 будут использованы значения, заданные в firebird.conf. а для baza2 – значение DefaultDbCachePages, указанное после алиаса baza2.
Частая ошибка, когда думают, что блок изменяемых параметров относится ко всем перечисленным алиасам до блока параметров в фигурных скобках.
Нет. Блок параметров в фигурных скобках должен быть указан для каждого алиаса, если для него требуются параметры, отличные от firebird.conf.
Одна или несколько баз данных на сервере
Одна база на сервере
По факту даже если на сервере есть только одна база, то база не одна, есть еще база пользователей security.fdb, но для нее в databases.conf указаны специальные значения кэша, чтобы обе эти базы не использовали одни и те же параметры.security.fdb обычно имеет крайне малый размер, и даже если ей задать огромный кэш, больше размера этого файла аллокировать кэш Firebird не станет. Но на всякий случай там всё равно указан размер кэша в 50 страниц, чего для базы аутентификации вполне достаточно даже для 1000 пользователей (хотя, в зависимости от частоты коннектов-дисконнектов размер кэша для security.fdb можно увеличить и до 250 страниц, и может быть более). Другие параметры для security.fdb вряд ли имеет смысл использовать.
примечание: в некоторых системах с большим количеством неизменяемых пользователей иногда ускорить аутентификацию помогает переключение security.fdb из режима read-write в режим read-only (gfix security…fdb –mode read_only. Однако, понятно, для добавления-удаления-модификации пользователей придется временно переводить такую базу в режим read-write
Две-три разных базы
В этом случае лучше всего сконфигурировать параметры баз в databases.conf, а firebird.conf в плане параметров баз не редактировать вообще.Сто одинаковых баз
В этом случае понятно, что не стоит создавать в databases.conf сто алиасов, и уж тем более задавать им свои конкретные параметры. Лучше отрегулировать firebird.conf.И если есть какие-то «выделяющиеся» базы, то тогда – да, только их прописать в databases.conf.
Загрузка измененных конфигов
firebird.conf – считывается сервером при старте SuperServer/SuperClassic, или при старте нового коннекта Classic (но это не влияет на существующие коннекты Classic).databases.conf – считывается при первом коннекте к БД (до отключения всех коннектов для SuperServer).
Таким образом, при изменении firebird.conf нужно рестартовать сервер Firebird, а при изменении databases.conf нужно убедиться, что все пользователи отключены от базы. Например, сделать gfix database –shut full –force 0, и затем gfix database –online.
Впрочем, для перечитывания databases.conf сделать рестарт Firebird не возбраняется.
Различие в кэшировании
Подробнее о кэшировании sort с FB 4.0
Вплоть до Firebird 3 параметр#TempCacheLimit = 64M
определял общий размер памяти для сортировок, в Classic на коннект, в SuperClassic (с 2.5) и SuperServer – для процесса.
Причем, память эта распределяется только по мере выполнения запросов, которые требуют сортировки результата в памяти (если выделенной памяти не хватит, сортировка продолжится на диске).
Начиная с Firebird 4 этот параметр теперь для каждой базы данных отдельный.
То есть, если этот параметр, как прежде, указан у вас только в firebird.conf, то для SuperClassic/SuperServer в 4.0 этот размер кэша будет выделяться не как общий для всех баз данных, а отдельно для каждой базы на этом сервере, к которой будут коннекты (разумеется, как было сказано выше, только при выполнении запросов с сортировкой результата).
Например, на сервере была одна база, на сортировки было задано 10 гиг в firebird.conf, появилась вторая база, и на сортировки теперь стало выделяться 2 раза по 10 гиг.
Поэтому, данный параметр с 4.0 стал Per database configurable, и его нужно регулировать уже в databases.conf для конкретной базы данных.
А в firebird.conf этот параметр можно оставить по умолчанию.
Кэш метаданных
До Firebird 3.0 у архитектуры SuperServer кэш метаданных был общим. Начиная с 3.0 у SuperServer кэш метаданных раздельный для каждого коннекта, а в SuperClassic Classic он и так был раздельным во всех версиях.Как определить размер кэша метаданных, хотя бы приблизительно?
Это можно сделать запросом, изложенным в статье
https://www.ibase.ru/db_meta_size
FileSystemCacheThreshold
Этот параметр появился в Firebird 2.5, и определяет порог для DefaultDbCachePages, с которого Firebird перестает использовать файловый кэш операционной системы для базы данных.Например, по умолчанию
FileSystemCacheThreshold = 64K
и если DefaultDbCachePages будет выше этого значения (в страницах БД), то файловый кэш ОС для базы данных отключится.
Поскольку работа кэша Firebird и операционной системы сильно отличается, то в результате будет сильное падение производительности ввода вывода. Подробнее можно почитать в статье (https://www.ibase.ru/files/articles/performance/Firebird%20Optimizer%20-%20ORDER%20vs%20SORT.pdf со стр. 10 ). Если в двух словах, то производительность работы с БД упадет примерно в 19 раз.
В Firebird 4 был введен параметр
UseFileSystemCache = true
который заставляет сервер игнорировать FileSystemCacheThreshold в случае true (т.е. по умолчанию), и учитывать в случае false.
Поскольку UseFileSystemCache по умолчанию включен, беспокоиться не о чем. Однако, если он выключен, и хочется оставить работу файлового кэша ОС, рекомендуется заранее (на всякий случай) выставить FileSystemCacheThreshold куда больше чем DefaultDbCachePages.
Например, если у вас
DefaultDbCachePages = 100000
не надо экономить и ставить
FileSystemCacheThreshold = 110000
Поставьте FileSystemCacheThreshold сразу в 2-3 раза больше (или десять), тогда вы не будете удивлены плохой производительности, если поставите на сервер больше памяти, и переконфигурируете DefaultDbCachePages например до 150000 страниц.
Напомню, что все эти параметры также регулируются для конкретной базы данных в databases.conf.
Интересный момент – FileSystemCacheThreshold начиная с 3.0 – раздельный для баз данных. Т.е. в databases.conf одной можно выключить файловый кэш БД, а другой – включить (если с 4.0 и выше выключить UseFileSystemCache в firebird.conf. Но такие эксперименты крайне сомнительные. Даже для микроскопической security.fdb лучше файловый кэш ОС не выключать.
LockMemSize
Раньше (и вообще для Classic и SuperClassic) это был важный параметр, который определял стартовый размер куска памяти для блокировок.Тогда была магическая формула для вычисления оптимального значения, поскольку этот кусок памяти перераспределялся при исчерпании, в результате чего в работе пользователей могла возникнуть пауза от одной секунды до нескольких секунд (из-за аллокирования нового большего куска памяти и копирования всех данных из старого в новый).
LockMemSize >= Cache_pages * max_connections_count * 100
Однако, для SuperServer и версий 3.0 и выше эта формула уже не работает, и нужно смотреть в вывод fb_lock_print при максимальном количестве пользователей
D:\Firebird5>fb_lock_print -d e.fdb
LOCK_HEADER BLOCK
Version: 19, Creation timestamp: 2025-09-17 13:33:22
Active owner: 0, Length: 1048576, Used: 92668
…
Смотрим на Length, увеличиваем на 10-20%, выставляем это значение LockMemSize в firebird.conf, и всё.
Что не конфигурируется
Кэш метаданных.Он раздельный для коннектов для SuperServer начиная с 3.0, и так же в 4.0 и 5.0.
Чего здесь нет
Здесь нет ничего про TCPBufferSize, который не надо менять вообще, или про настройки таймаутов, или про другие параметры firebird.conf, которые относятся исключительно к серверу. Это тема для отдельной статьи.Чатботы и файлы конфигураций
Ни в коем случае! Недавно один человек прислал в группу https://t.me/firebird_friday содержимое firebird.conf с просьбой посмотреть, правильно всё, или нет.Поначалу шли нормальные параметры, правда значения были подобраны несколько странно, а потом в тексте пошли абсолютно вымышленные имена параметров со значениями «с потолка».
Оказалось, что такой файл конфигурации сгенерировал чатбот (т.е. ChatGPT или какая-то другая нейросеть). Видимо, он галлюцинировал, а также взял часть параметров из конфигураций других СУБД.
Я даже не буду приводить пример таких параметров, чтобы на них не было ссылок в эту статью.
Но вот такое использовать категорически не надо.
Пользуйтесь человеческим калькулятором конфигураций https://cc.ib-aid.com/, который подбирает параметры не с потолка, а по нашему многолетнему опыту. Или читайте статьи, экспериментируйте, приобретайте опыт и конфигурируйте Firebird самостоятельно.
Или обращайтесь к нам за технической поддержкой - https://www.ibase.ru/techsupp/ .
Статьи и видео
- Тюнинг Firebird и Linux для БД размером 691гб с 1000+ пользователей
https://habr.com/ru/post/476636/ - Руководство по аппаратному обеспечению (hardware) для Firebird
https://www.ibase.ru/files/firebird/Firebird_Hardware_Guide_2015_rus.pdf - Firebird 3: Архитектуры Classic, SuperClassic, SuperServer
https://rutube.ru/video/47247a1d7cf3897d2106c342cfb66435/ - The biggest configuration error in Firebird SQL
https://ib-aid.com/download/docs/2024/the_biggest_configuration_error_in_Firebird.pdf
Вопросы? support@ibase.ru.