Firebird 4 что нового
Вышел Firebird 4.0
Сегодня, 1 июня 2021 года, выпущен Firebird 4.0 — седьмой основной выпуск СУБД Firebird, разработка которого началась в 2016 году. Ключевой задачей при разработке Firebird 4.0 было повышение доступности баз данных (синхронная и асинхронная логическая репликация).
Одно из важнейших улучшений в Firebird 4.0 — изменение подхода к созданию согласованного представления о состоянии базы данных, видимом для выполняющихся транзакций. Новый подход позволил решить проблему согласованного чтения на уровне запроса в транзакциях Read Committed Read Consistency, а также ввести так называемую промежуточную сборку мусора. Промежуточная сборка мусора позволяет дополнительно сокращать длины цепочек версий при наличии долгих активных транзакций.
Далее мы перечислим ключевые улучшения, сделанные в Firebird 4.0, и их краткое описание. Подробное описание всех изменений можно прочитать в Firebird 4.0 Release Notes
Среди важных улучшений также можно отметить поддержку чисел с точностью более 18 цифр, улучшение точности вычислений для более коротких чисел, поддержка часовых поясов, увеличение длины имён метаданных до 63 символов, улучшение подсистемы безопасности, копии постоянной готовности (physical standby) на основе nbackup, таймауты простоя соединения и выполнения SQL запроса, Batch API, а также множество новых возможностей языка SQL.
Далее мы перечислим ключевые улучшения, сделанные в Firebird 4.0, и их краткое описание. Подробное описание всех изменений можно прочитать в «Firebird 4.0 Release Notes».
Логическая репликация
В Firebird 4.0 предоставляет встроенную поддержку однонаправленной логической репликации. Репликация, в первую очередь обеспечивает высокую доступность, но может использоваться и для других задач.
Репликация отслеживает следующие события:
Поддерживаются синхронный и асинхронный режимы.
При синхронной репликации основная (главная) база данных постоянно подключена к репликам (подчиненным базам данных) и изменения реплицируются немедленно. По сути, базы данных синхронизируются после каждой фиксации каждой транзакции, что может повлиять на производительность из-за дополнительного сетевого трафика.
При асинхронной репликации изменения записываются в файлы локального журнала, передаются по сети и применяются к реплике базы данных. Влияние на производительность намного меньше, но вызывает задержку (отставание репликации) пока изменения ожидают применения к реплике базы данных, т.е. реплика базы данных всегда «догоняет» основную базу данных.
Копии постоянной готовности (nbackup physical standby)
Утилита nBackup в Firebird 4 может выполнять физическое резервное копирование, которое использует GUID (UUID) самой последней резервной копии базы данных, доступной только для чтения. Изменения (дельты) из исходной базы данных можно последовательно (по одной)
применять к резервной базе данных, без необходимости сохранять и применять (сразу) все дельты с момента последней полной резервной копии.
Новый способ оперативного резервирования можно запустить, не затрагивая действующую многоуровневую схему резервного копирования базы данных.
Пул внешних подключений
Тайм-ауты
В Firebird 4.0 добавлены настраиваемые тайм-ауты:
Тайм-аут простоя сеанса позволяет пользовательскому соединению автоматически закрываться после определенного периода бездействия.
Тайм-аут выполнения SQL запроса, позволяет автоматически останавливать выполнение запроса, если он выполняется дольше заданного периода тайм-аута.
Слепки состояния базы данных (database snapshots) на основе порядка фиксации
В Firebird 4.0 кардинально переработана концепция создания слепков состояния базы данных (database snapshot). Ранее для создания слепков (snapshot) требовалось создать копию TIP (transaction inventory page), в Firebird 4 достаточно просто запомнить номер фиксации (Commit Number). Таким образом, процесс создания слепка в Firebird 4 требует значительно меньше ресурсов, чем ранее.
Режим изолированности READ COMMITTED READ CONSISTENCY
Промежуточная сборка мусора
Ранее ненужные версии записей (мусор) могли быть удалены только для версий, созданных транзакцией, номер которой меньше чем OST (Oldest Snapshot Transaction). То есть мусор можно было удалить только из конца цепочки версий. Новая концепция создания слепков состояния базы данных (database snapshot) позволила удалять мусор в цепочке версий между активными версиями записи (версий для которых есть активный слепок состояния). Это позволяет значительно сократить длину цепочки версий при наличии длительных активных транзакций и сократить их негативное влияние на производительность.
Совместное использование SNAPSHOT транзакций
С помощью этой функции можно создавать параллельные процессы (с использованием разных соединений), читающие согласованные данные из базы данных. Например, процесс резервного копирования может создать несколько потоков, параллельно считывающих данные из базы данных.
Поддержка международных часовых поясов
Поддерживаются выражения и операторы для работы с типами с часовыми поясами, а также преобразование между типами данных без/с часовыми поясами.
Повышенная точность хранения и вычисления для типов NUMERIC и DECIMAL
Типы NUMERIC и DECIMAL теперь могут хранить числа с точностью до 38 цифр. Для хранения чисел с точностью более 18 цифр Firebird 4.0 использует тип INT128 (128 битное целое). Кроме того улучшена обработка промежуточных результатов вычислений с типами данных NUMERIC и DECIMAL. В предыдущих версиях Firebird числа, внутренне представленные типом данных
BIGINT (то есть с точностью от 10 до 18 десятичных цифр), умножались/делились с использованием того же типа данных BIGINT для промежуточных вычислений, что могло вызвать ошибки переполнения из-за ограничения доступной точности. В Firebird 4 такие вычисления выполняются с использованием 128-битных целых чисел, что снижает вероятность неожиданных переполнений.
Тип INT128 также доступен для использования.
Тип данных DECFLOAT
DECFLOAT — это числовой тип, соответствующий стандарту SQL:2016, который точно хранит числа с плавающей запятой (десятичный тип с плавающей запятой), в отличие от FLOAT или DOUBLE PRECISION, обеспечивающие двоичное приближение предполагаемой точности. Firebird 4 соответствует типам Decimal64 и Decimal128 из стандарта IEEE 754-1985, обеспечивая для этого типа как 16-значную, так и 34-значную точность.
Все промежуточные вычисления производятся с 34-значными значениями.
Поддержка пакетных операций для параметризованных запросов в API
OO-API в Firebird 4 поддерживает пакетное выполнение SQL операторов (с одним и более наборов параметров). Batch API позволяет производить операции импорта данных по сети более эффективно, поскольку значительно снижается количество сетевых пакетов.
Batch API теперь используется в gbak при восстановлении базы данных из резервной копии. Таким образом процесс восстановления с использованием сетевых протоколов происходит быстрее.
Виртуальная таблица RDB$CONFIG
Добавлена новая виртуальная таблица RDB$CONFIG. В этой таблице перечислены параметры конфигурации, актуальные для текущей базы данных. Таблица RDB$CONFIG заполняется из структур в памяти по запросу, и ее экземпляр сохраняется на время существования SQL запроса.
Улучшение производительности сортировок
Исторически сложилось, что когда выполняется внешняя сортировка, Firebird записывает в блоки сортировки как ключевые поля (перечислены в предложениях ORDER BY или GROUP BY), так и не ключевые (все остальные) поля запроса. После завершения сортировки (все) поля запроса вычитываются из блоков сортировки, находящихся в памяти или/и во (временных) файлах. Этот подход обычно считается более быстрым, поскольку записи читаются в порядке хранения вместо случайной выборки страниц данных, соответствующих отсортированным записям. Однако, если не ключевые поля велики (например, задействованы длинные VARCHAR), то они увеличивают размер блоков сортировки, провоцируя их вытеснение на диск и более интенсивный ввод-вывод для временных файлов. Firebird 4 предоставляет альтернативный подход, когда только ключевые поля и записи DBKEY хранятся внутри блоков сортировки, а не ключевые поля повторно выбираются со страниц данных после сортировки. Это улучшает производительность сортировки в случае длинных не ключевых полей.
Улучшения SQL
Улучшения DDL
Увеличена максимальная длина идентификаторов до 63 символов. Метаданные теперь хранятся в кодировке UTF-8 вместо устаревшей кодировки UNICODE_FSS (ранняя версия реализации UNICODE).
Добавлены операторы для настройки набора таблиц, которые включены в публикацию. Публикация — набор таблиц, включенных в процесс репликации.
Улучшения DML
Добавлена возможность использовать предложение OVERRIDING для IDENTITY полей.
Добавлена поддержка предложения кадра (frames) для оконных функций. Кадром называется набор строк внутри секции которым оперирует оконная функция.
Пример использования кадров (рамки окна):
Улучшения PSQL
Операторы управления сеансовым окружением
В Firebird 4.0 появился новый класс SQL операторов — так называемые операторы управления сеансовым окружением. Обычно такие операторы начинаются с глагола SET, некоторые из них начинаются с ключевого слова ALTER.
Данные SQL операторы работают вне механизма транзакций, и выполненные ими изменения вступают в силу немедленно.
Операторы управления сеансовым окружением доступны, в том числе и в PSQL коде. Они особенно полезны в ON CONNECT триггерах.
Операторы управления сеансовым окружением разбиты на следующие группы:
Улучшение безопасности
Системные привилегии
Эта функция позволяет предоставлять и отменять некоторые специальные привилегии обычным пользователям для выполнения задач, которые исторически ограничивались только SYSDBA, например: запуск утилит gbak, gfix, nbackup, доступ к таблицам мониторинга, запуск пользовательской трассировки и т.д.
Набор системных привилегий может быть указан при создании/изменении роли.
Выдача ролей другой роли
Ключевое слово DEFAULT в операторах GRANT и REVOKE
Если в операторе GRANT используется ключевое слово DEFAULT, то роли используются пользователем или ролью каждый раз, даже без явного указания. При подключении пользователь получит привилегии всех ролей, которые были назначены с использованием ключевого слова DEFAULT. Если пользователь укажет свою роль при подключении, то получит привилегии этой роли (если она была ему назначена) и привилегии всех ролей, назначенных ему с использованием ключевого слова DEFAULT.
SQL SECURITY
Все объекты метаданных, содержащие DML или PSQL код, могут выполнятся в одном из следующих режимов:
Исторически сложилось, что все PSQL модули по умолчанию выполняются с привилегиями вызывающего пользователя. Начиная с Firebird 4.0 появилась возможность указывать объектам метаданных с какими привилегиями они будут выполняться: вызывающего или определяющего пользователя. Для этого используется предложение SQL SECURITY, которое можно указать для таблицы, триггера, процедуры, функции или пакета. Если выбрана опция INVOKER, то объект метаданных будет выполняться с привилегиями вызывающего пользователя. Если выбрана опция DEFINER, то объект метаданных будет выполняться с привилегиями определяющего пользователя (владельца). Эти привилегии будут дополнены привилегиями, выданными самому PSQL модулю оператором GRANT.
В данном случае пользователю JOE достаточно только привилегии EXECUTE на процедуру p. Если бы процедура была создана с привилегиями вызывающего пользователя (опция INVOKER), то ещё потребовалось бы выдать привилегию INSERT для процедуры p на таблицу t.
Встроенные криптографические функции
В Firebird 4.0 добавлено множество встроенные криптографических функций. Вы можете использовать их для шифрования значений отдельных столбцов в таблице или других задач.
Поддержка шифрования утилитой gbak
Поддержка шифрования базы данных была введена ещё в Firebird 3.0, однако шифровать/дешифровать файлы резервной копии сделанной утилитой gbak можно было только внешними инструментами. В Firebird 4.0 добавлена поддержка шифрования резервной копии с помощью того же плагина шифрования, что используется при шифровании базы данных.
Пример создания шифрованной резервной копии
Резервная копия шифруется с помощью того же самого плагина шифрования, с которым зашифрована база данных.
Пример восстановления резервной копии
Вы также можете указать плагин шифрования отличный от умолчательного.
Firebird 4 что нового
Join Firebird!
Join Firebird Foundation to support Firebird SQL development and receive multiple bonuses
Follow Us
Select your media preference
Newsletter
Subscribe to Firebird’s Newsletter to receive the latest news
Firebird 4.0 introduces new data types and many improvements without radical changes in architecture or operation, the most important are: logical replication, longer metadata identifiers, international time zone support, timeouts for connections and statements.
Documentation: Release Notes (PDF available), Language Reference (PDF available) and other manuals.
 Win32 | Win64 |  Linux x86 | Linux AMD64 |  Android ARM32 | Android ARM64 |
| Release Date | File Name | Size | Description |
| Sources | |||
| June 1, 2021 | Firebird-4.0.0.2496-0.tar.xz | 29 MB | Compressed tarball |
| Win32 | |||
| 32-bit Kits | |||
| June 1, 2021 | Firebird-4.0.0.2496-1-Win32.exe | 15 MB | Windows executable installer, recommended for first-time users |
| June 1, 2021 | Firebird-4.0.0.2496-1-Win32.zip | 21 MB | Zip kit for manual/custom installs |
| 32-bit Debug Kits (Binary + PDB components) | |||
| June 1, 2021 | Firebird-4.0.0.2496-1-Win32-pdb.exe | 28 MB | Windows executable installer (debug information included) |
| June 1, 2021 | Firebird-4.0.0.2496-1-Win32-pdb.zip | 45 MB | Zip kit for manual/custom installs (debug information included) |
| Win64 | |||
| 64-bit Kits | |||
| June 1, 2021 | Firebird-4.0.0.2496-1-x64.exe | 17 MB | Windows executable installer, recommended for first-time users |
| June 1, 2021 | Firebird-4.0.0.2496-1-x64.zip | 23 MB | Zip kit for manual/custom installs |
| 64-bit Debug Kits (Binary + PDB components) | |||
| June 1, 2021 | Firebird-4.0.0.2496-1-x64-pdb.exe | 33 MB | Windows executable installer (debug information included) |
| June 1, 2021 | Firebird-4.0.0.2496-1-x64-pdb.zip | 47 MB | Zip kit for manual/custom installs (debug information included) |
| Linux x86 | |||
| 32-bit Kits | |||
| June 1, 2021 | Firebird-4.0.0.2496-0.i686.tar.gz | 21 MB | Compressed tarball |
| June 1, 2021 | Firebird-debuginfo-4.0.0.2496-0.i686.tar.gz | 175 MB | Debug build, compressed tarball |
| Linux AMD64 | |||
| 64-bit Kits | |||
| June 1, 2021 | Firebird-4.0.0.2496-0.amd64.tar.gz | 19 MB | Compressed tarball |
| June 1, 2021 | Firebird-debuginfo-4.0.0.2496-0.amd64.tar.gz | 179 MB | Debug build, compressed tarball |
| IMPORTANT! Android builds were not thoroughly tested, therefore they should be treated as experimental. Please report any problems you experience to the development mailing list. | |||
| Android ARM32 | |||
| 32-bit Kits | |||
| June 1, 2021 | Firebird-4.0.0.2496-0.arm.tar.gz | 14 MB | Compressed tarball |
| June 1, 2021 | Firebird-withDebugInfo-4.0.0.2496-0.arm.tar.gz | 66 MB | Debug build, compressed tarball |
| Android ARM64 | |||
| 64-bit Kits | |||
| June 1, 2021 | Firebird-4.0.0.2496-0.arm64.tar.gz | 16 MB | Compressed tarball |
| June 1, 2021 | Firebird-withDebugInfo-4.0.0.2496-0.arm64.tar.gz | 66 MB | Debug build, compressed tarball |
Firebird 4.0 introduces new data types and many improvements without radical changes in architecture or operation, the most important are: logical replication, longer metadata identifiers, international time zone support, timeouts for connections and statements.
Разработка не стандартных решений
Мы не являемся разработчиками программы Тирика-Магазин
Переход на Firebird 4.0.0 (32бит) + сравнение версий в работе.
Переход на Firebird 4.0.0 (32бит) + сравнение версий в работе.
Сообщение Vitaly » 04 июн 2017, 20:50
Так как данная версия базы НЕ является официальной, то тут не будет инструкции как на нее перейти.
Во избежания потери данных.
Вы можете сами изучить этот момент и перейти, или мы можем помочь Вам.
Свершилось. Ко мне в руки попал Firebird 4.0
Пока что возможно только ПОЛНОСТЬЮ ручная установка его.
Сейчас проверяется работа базы одного из пользователей Тирики.
Размер базы 172 мегабайта на данный момент времени. (остальные данные не разглашаются)
Re: Переход на Firebird 4.0.0 (32бит)
Сообщение Vitaly » 05 июн 2017, 17:41
Итак, более подробные результаты тестирования (тестировал 32 битку, но есть и 64 битный)
ОДИН И ТОТ ЖЕ КОМПЬЮТЕР.
ТОТ ЖЕ ВИНДОВС.
База ИДЕНТИЧНА.
разные фарберды.
— УСЛОВИЯ ИДЕНТИЧНЫЕ.
ОБРАТИТЕ внимание.
Firebird использовался с сайта производителя, с сайта Тирики он не использовался! Для чистоты проверки!
Firebird настраивались вручную, что бы конфиги были максимально похожи!
8293 наименований товаров
131384 продаж
Версия Тирики 7.2.58
Версии Firebird видны на скриншотах
Тюнинг Firebird и Linux для БД размером 691 Гб с 1000+ пользователей
Firebird является очень популярной открытой СУБД в России, и, несмотря на отсутствие шумных маркетинговых акций, используется в большом количестве ответственных систем, особенно в медицинских и государственных системах автоматизации.
Размер БД и количество активных пользователей в таких системах обычно достаточно большие, поэтому в этой статье я расскажу об опыте оптимизации настроек Firebird и Linux, основываясь на конкретных примерах больших БД Firebird в компаниях БудьЗдоров (Ингосстрах), АльфаЗдрав, и затрону опыт других компаний по оптимизации Firebird+Linux.
Давайте подробнее познакомимся с предметом оптимизации — СУБД Firebird 3.0.5 (с расширениями HQbird), обслуживает БД размером 691Гб (на текущий момент) с ежедневными 1000-1100 пользователями, работает на Linux CentOS 7, сервер — железный HP DL380. Для БД настроена репликация на резервный сервер (вопрос о репликации вне рамок этой статьи).
СУБД обслуживает медицинскую информационную систему Инфоклиника (производства российской компании Smart Delta Systems), которая является одной из самых популярных медицинских информационных систем в России.
Давайте взглянем на подробности (скриншоты далее взяты из HQbird) работы этой базы данных:
Данные интенсивно вставляются в БД — ежедневный прирост около 0.4 — 0.5 Гб
1000-1100 соединений это обычная дневная нагрузка:
Несмотря на интенсивный рост и активную работу, база данных не содержит сколько-нибудь значительного количества мусорных версий записей — как благодаря приложениям, написанным с хорошим знанием многоверсионной архитектуры, так и благодаря адекватно настроенной сборке мусора:
Маркеры транзакций в «зеленой» зоне:
Кстати, обратите внимание, что данные в БД — строковые, блобы присутствуют, но их мало — всего 10Гб из 690Гб общего размера.
Характер нагрузки на БД смешанный, 75% операций чтения и 25% записи:
Железо
Сервер, который обслуживает эту систему, неплохой, но далеко не топовый:
Дисковая подсистема состоит из двух частей: локальный диск на 745Gb и двойной 2 fibre-channel connection к SAN, с разделом на 1.8Тб.
Операционная система
Используется CentOS 7, версия ядра:
На логичный вопрос, почему не используется самое современное ядро и CentOS 8, ответ тоже логичный — миграция ответственных систем происходит только после выпуска нескольких минорных релизов и тщательного тестирования — это один из тех случаев, когда известный баг лучше двух неизвестных.
Однако, надо отметить, что до 2017 года система работала на CentOS 6.x, и после миграции было отмечено значительное улучшение показателей производительности.
Настройка Linux
Абсолютно необходимая настройка Linux для Firebird
Есть 2 параметра, которые нужно обязательно увеличить на всех серверах Linux, где работает Firebird — число виртуальных областей памяти (virtual memory areas, VMA) и число открытых файлов для процесса Firebird.
Число VMA по умолчанию 64K, его необходимо увеличить в 4 раза, для этого в sysctl.conf надо добавить строку
Чтобы проверить текущее значение, используйте команду
На каждое соединение к БД Firebird открывает до 20 описателей (файловых хэндлов) включительно (учитывая тот факт, что в Linux все ресурсы выглядят как файлы), поэтому максимальное количество открытых файлов по умолчанию (обычно 4096) может очень быстро исчерпаться.
Чтобы проверить доступное количество файлов для Firebird, лучше всего посмотреть лимиты исполняемого файла Firebird:
где проверить значение для Max Open Files и увеличить их при необходимости.
Чтобы увеличить параметр Max Open Files для Firebird, в файл firebird-superserver.service в секцию [service] мы добавили строку:
Опциональная настройка Linux
На этом сервере мы также сделали следующие настройки
1. Уменьшили swapiness
Так как сервер является выделенным эксклюзивно для СУБД Firebird, и мы желаем эффективно использовать RAM под кэш СУБД и кэш файлов операционной системы, то уменьшаем swapiness c дефолтных 60% до 10%, для этого в sysctl.conf добавили
2. Увеличили минимальный зарезервированный размер памяти для специальных процессов ОС
т. е. 1Гб памяти. Эта настройка косвенно влияет на дефрагментацию памяти.
Обратите внимание, что эта настройка индивидуальна — с учетом того, что у нас 320Гб RAM, 1Гб это не так уж и много, но в случае небольшого количества памяти (например, 32Гб), 1Гб мог бы быть перебором.
3. Уменьшили keepalive
Firebird полагается на keepalive интервалы, чтобы проверять состояние соединения, и по умолчанию значение keepalive может быть очень большим. Ограничивая его до 300 секунд, мы избавляемся от зависших соединений
Еще больше тюнинга Linux
Почему мы ограничились таким небольшим количество настроек Linux?
Во-первых, мы придерживаемся консервативного подхода к тюнингу серверов с Linux (который становится все лучше и лучше с каждой новой версией), во-вторых, эта база данных Firebird не является ни экстремально большой, ни самой нагруженной, и Linux с указанными настройками справляется со своими задачами.
Конечно, существует еще несколько настроек, которые можно использовать для оптимизации работы Firebird на Linux — например, ряд интересных вещей был представлен в презентации о 3 Тб базе данных Firebird (РедБаза) в Федеральной Службе Приставов.
Настройка Firebird
Конфигурационные файлы коммьюнити дистрибутива Firebird с firebirdsql.org настроены очень консервативно, и на мало-мальски мощном сервере необходимо изменять конфигурационные файлы, а также тщательно выбирать используемую архитектуру (в Firebird 3.0 существует 2 вида подключения: Embedded и NetworkServer, и 3 вида архитектур: SuperServer, SuperClassic, Classic).
Также, необходимо использовать настройки для каждой БД — т.е. помещать критические настройки в databases.conf, с привязкой к конкретной базе данных.
В нашем случае выбрана архитектура SuperServer, наиболее популярная в версии 3.0, т.к. она эффективно использует многоядерные процессоры и имеет совместный для всех соединений кэш (но отдельный на каждую БД).
Ниже приведены конфигурационные файлы (только значения, относящиеся к производительности):
firebird.conf — конфигурационный файл для всех БД на сервере
С точки зрения производительности, ключевыми параметрами здесь являются следующие:
1. DefaultDbCachePages = 50K # измеряется в страницах, на БД, при странице 16К = 0.8Gb
Размер страничного кэша DefaultDbCachePages в firebird.conf специально установлен по умолчанию в 800Mb — для того, чтобы случайно затесавшаяся на сервере тестовая БД не попыталась занять огромное количество оперативной памяти.
2. FileSystemCacheThreshold = 300K # pages
Важно устанавливать этот параметр в значение большее, чем DefaultDBCachePages, чтобы разрешить использование файлового кэша ОС.
3. TempCacheLimit = 20480M # bytes
Это параметр устанавливает размер памяти для запросов с сортировками (и некоторыми другими операциями), и является индивидуальным для каждой системы.
В результате мониторинга размеров сортировок мы выяснили, что 20Гб является оптимальным для данной БД.
4. LockMemSize и LockHashSlots — параметры таблицы блокировок
Эти параметры определяют начальный размер таблицы блокировок и количество слотов для вычисления хэш функции.
Настройка сжимает трафик между клиентами и серверов, особенно это полезно при интенсивных Execute Statement On External, которые выполняет клиентское приложение.
Остальные параметры описаны в самом firebird.conf и сопутствующей документации Firebird и HQbird.
Наиболее важные настройки мы вынесли в databases.conf, с точным указанием БД
Как вы можете догадаться, основная сложность в данном случае состоит в том, как верно рассчитать размер памяти, выделяемой нашей большой БД.
Для Firebird 3.0 c архитектурой SuperServer существует два подхода — консервативный, который используется на серверах с небольшим количеством оперативной памяти (до 32Гб включительно), который заключается в том, чтобы выделять под страничный кэш не более 25% RAM, и в остальном полагаться на файловый операционной системы, и тонкая настройка, когда мы точно определяем оптимальный размер для сортировок, выделяем определенный размер памяти для ядра ОС, резервируем определенный объем памяти для массивных файловых операций (например, резервное копирование), и остаток выделяем на страничный кэш.
Во втором случае нет возможности сразу получить оптимальный размер кэша, т. к. характер нагрузки может сильно отличаться для разных типов БД, но после нескольких итераций можно добиться отличного результата.
Типичные ошибки в настройке Firebird
К типичным ошибкам относятся следующие:
1) Явно указанный на странице заголовка БД размер страничного кэша, который переопределяет значения, указанные в firebird.conf и databases.conf.
Особенно часто эта ошибка возникает при смене архитектуры с Classic/SuperClassic на SuperServer — если при явно указанном небольшом (500-2000 страниц) размере кэша на соединение Classic/SuperClassic работают нормально, то для SuperServer необходим гораздо больший кэш.
Чтобы проверить, выполните команду
и проверьте значение Page Buffers — оно должно быть равно 0, тогда Firebird будет использовать значения из databases.conf или firebird.conf.
Для сброса установки страничного кэша на заголовочной странице выполните команду
2) При увеличении страничного кэша забывают увеличить FileSystemCacheThreshold, что ведет к отключению файлового кэша, что снижает производительность.
3) Использование размера страницы БД по умолчанию (4096 или 8192), в то время как для больших БД необходимо использовать 16К.
Заключение
В целом, 1000+ пользователей Firebird на железе, соответствующем нагрузке, настроенном Linux и сконфигурированном Firebird, работают без проблем. На данном сервере по производительности есть запас, который был протестирован в пиках нагрузки до 1500-1800 пользователей.
Среди Linux-дистрибутивов для БД Firebird c подобной нагрузкой наиболее популярен CentOS 7, рекомендуемая версия — Firebird 3.0.