Firebird — очень популярная открытая СУБД в России, и, несмотря на отсутствие шумных маркетинговых кампаний, она используется в большом количестве критически важных систем, особенно в системах автоматизации медицины и государственного управления.
Размер базы данных и количество активных пользователей в таких системах обычно довольно велики, поэтому в этой статье я расскажу об опыте оптимизации настроек Firebird и Linux на конкретных примерах больших баз данных Firebird в компаниях.
Быть здоровым (Ингосстрах), АльфаЗдрав и затронем опыт других компаний по оптимизации Firebird+Linux. Остановимся подробнее на предмете оптимизации - СУБД Firebird 3.0.5 (с расширениями HQbird), обслуживает базу данных объемом 691ГБ (на данный момент) с 1000-1100 ежедневными пользователями, работает на Linux CentOS 7, сервер - железо HP DL380. База данных настроена на репликацию на резервный сервер (вопрос репликации выходит за рамки данной статьи).
СУБД обслуживает медицинскую информационную систему «Инфоклиника» (производства российской компании Умные дельта-системы ), которая является одной из самых популярных медицинских информационных систем в России.
Давайте подробно рассмотрим (скриншоты ниже взяты из HQbird) того, как работает эта база данных: Данные интенсивно вставляются в базу данных — ежедневный прирост составляет около 0,4 — 0,5 ГБ.
1000-1100 подключений — это типичная ежедневная нагрузка: 
Несмотря на интенсивный рост и активную работу, в базе данных не содержится сколько-нибудь существенного количества мусорных версий записей — как благодаря приложениям, написанным с хорошим знанием многоверсионной архитектуры, так и благодаря адекватно настроенной сборке мусора: 
Маркеры сделок в «зеленой» зоне: 
Кстати, обратите внимание, что данные в базе — это строковые данные, есть блобы, но их немного — всего 10ГБ из общего размера в 690ГБ.
Характер нагрузки на БД смешанный, 75% операций чтения и 25% операций записи: 
Железо
Сервер, обслуживающий эту систему, неплох, но далеко не топовый:Дисковая подсистема состоит из двух частей: локального диска 745Гб и двойного 2-х оптоволоконного подключения к SAN, с разделом 1,8ТБ.HP ProLiant DL380p Gen8, Gen8 2x Xeon(R) CPU E5v2 @ 2.60GHz, 24 logical cores with HT 320Gb RAM, 4 network cards
Операционная система
Используется CentOS 7, версия ядра: Linux version 3.10.0-957.21.3.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Tue Jun 18 16:35:19 UTC 2019
На логичный вопрос, почему не используется самое современное ядро и CentOS 8, ответ тоже логичен — миграция критичных систем происходит только после нескольких минорных релизов и тщательного тестирования — это один из тех случаев, когда известная ошибка лучше, чем двое неизвестных.
Однако следует отметить, что до 2017 года система работала на CentOS 6.x, и после миграции было отмечено значительное улучшение производительности.
Настройка Linux
Абсолютно необходимая настройка Linux для Firebird
Есть 2 параметра, которые необходимо увеличить на всех Linux-серверах под управлением Firebird — количество областей виртуальной памяти (VMA) и количество открытых файлов для процесса Firebird. 1. ВМА Номер VMA по умолчанию — 64К, его необходимо увеличить в 4 раза, для этого нужно добавить строку в sysctl.conf vm.max_map_count=262144Чтобы проверить текущее значение, используйте команду
sysctl vm.max_map_count2. Максимальное количество открытых файлов Для каждого подключения к базе данных Firebird открывает до 20 дескрипторов (дескрипторов файлов) включительно (учитывая тот факт, что в Linux все ресурсы выглядят как файлы), поэтому максимальное количество открытых файлов по умолчанию (обычно 4096) может быть исчерпано очень быстро.
Чтобы проверить доступное количество файлов для Firebird, лучше всего посмотреть ограничения на исполняемые файлы Firebird: cat /proc/$(pgrep firebird)/limits
где проверить значение «Максимальное количество открытых файлов» и при необходимости увеличить его.
Чтобы увеличить параметр Max Open Files для Firebird, мы добавили строку в файл firebird-superserver.service в раздел [service]: LimitNOFILE=49999
Дополнительная установка Linux
На этом сервере мы также сделали следующие настройки 1. Уменьшение подкачки Так как сервер выделен исключительно под СУБД Firebird, а мы хотим эффективно использовать оперативную память для кэша СУБД и файлового кэша операционной системы, то уменьшаем swapiness с дефолтных 60% до 10%, для этого мы добавили в sysctl.conf vm.swappiness=102. Увеличен минимальный размер зарезервированной памяти для специальных процессов ОС.
vm.min_free_kbytes=1048576
то есть 1 ГБ памяти.
Эта настройка косвенно влияет на дефрагментацию памяти.
Обратите внимание, что эта настройка индивидуальна — учитывая, что у нас 320 ГБ ОЗУ, 1 ГБ — это не так уж и много, но в случае небольшого объема памяти (например, 32 ГБ) 1 ГБ может быть лишним.
3. Уменьшение поддержки активности Firebird использует интервалы поддержки активности для проверки состояния соединения, а значение поддержки активности по умолчанию может быть очень большим.
Ограничив его 300 секундами, мы избавляемся от зависших соединений.
net.ipv4.tcp_keepalive_time=300
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_keepalive_intvl=15
Еще больше настроек Linux
Почему мы ограничены таким небольшим количеством настроек Linux? Во-первых, мы придерживаемся консервативного подхода к настройке Linux-серверов (который становится все лучше и лучше с каждой новой версией), а во-вторых, эта база данных Firebird не является ни чрезвычайно большой, ни самой нагруженной, и Linux с заданными настройками справляется с вашими задачами.Конечно, есть еще несколько настроек, которые можно использовать для оптимизации Firebird в Linux — например, в презентации о базе данных Firebird объемом 3 ТБ (RedBase) в Федеральной службе судебных приставов.
Настройка Firebird
Конфигурационные файлы дистрибутива сообщества Firebird с сайта firebirdsql.org настроены очень консервативно, и на более-менее мощном сервере необходимо менять конфигурационные файлы, а также тщательно выбирать используемую архитектуру (в Firebird 3.0 есть 2 типа соединений: Embedded и NetworkServer, а также 3 типа архитектур: SuperServer, SuperClassic, Classic).Также необходимо использовать настройки для каждой базы данных — т.е.
размещать критические настройки в datas.conf, привязанные к конкретной базе данных.
В нашем случае мы выбрали архитектуру SuperServer, наиболее популярную в версии 3.0, поскольку она эффективно использует многоядерные процессоры и имеет общий кэш для всех соединений (но отдельный для каждой базы данных).
Ниже приведены файлы конфигурации (только значения, связанные с производительностью): firebird.conf — файл конфигурации для всех баз данных на сервере.
DefaultDbCachePages = 50K
Теги: #linux #открытый исходный код #Администрирование баз данных #Конфигурация Linux #sql #настройка #firebird #Firebird/Interbase
-
Вы Участвовали В Часе Земли?
19 Oct, 24 -
Вход В Yii 2.0 И Psr-3
19 Oct, 24
