Настройка базы данных Firebird SQL объемом 1,7 терабайта
Alexey Kovyazin, 14 июля 2014
Как вы помните из наших предыдущих статей, мы исследовали мифы о деградации производительности Firebird ( /ru/articles/firebird-performance-degradation-tests-myths-and-truth/), где мы создали несколько баз данных от 9 ГБ до 30 ГБ, а также протестировали очень большую базу данных Firebird (1,7 терабайта) (/ru/articles/more-details-about-1-7-terabyte-firebird-sql-database/).
Все тесты проводились на одном и том же оборудовании, которое является довольно бюджетной конфигурацией: CPU AMD-FX8350, 16 ГБ ОЗУ, программный RAID1 SATA 2x4Tb HDD Seagate, операционная система Windows Server 2008R2 (2008R2 - 64-битная), и с одинаковой конфигурацией Firebird: это был Firebird 2.5.2 64-битный, SuperServer, с увеличенными буферами страниц и TempCacheSize. Вы можете бесплатно скачать этот файл конфигурации SuperServer по этой ссылке: /ru/optimized-firebird-configuration/
В результате мы получили следующую картину производительности базы данных:
Рисунок 1. Деградация производительности от 9 ГБ до 30 ГБ и 1,7 ТБ
Точка №11 - это показатель производительности для базы данных 30 ГБ, а №12 - для базы данных 1,7 терабайта - размер базы данных вырос в 60 раз (с 30 ГБ до 1813 ГБ), потеря производительности составила 2,4 раза (с 407 до 169 баллов).
Итак, вопрос: можем ли мы улучшить производительность Firebird на том же оборудовании с помощью настройки конфигурации?
И ответ: да!
Разгон FirebirdSQL
Как вы помните, в этом тесте мы запускали 20 одновременных подключений, которые выполняют интенсивные INSERT и менее интенсивные UPDATE.
Все SELECT короткие и хорошо определенные, с эффективными планами выполнения SQL, так что это типичное OLTP-приложение (обработка онлайн-транзакций). Для таких приложений наиболее критичным для производительности является параллельная обработка. Firebird SuperServer 2.5.2 плохо подходит для многопоточной обработки - он эффективно использует только 1 ядро на базу данных, и этот факт делает SuperServer не очень хорошим выбором для OLTP-приложений.
Итак, нам нужно изменить архитектуру Firebird на Classic или SuperClassic, которые поддерживают многопоточную обработку и используют несколько ядер CPU (в CPU AMD-FX8350 8 ядер).
Затем потребуется некоторая настройка, поскольку конфигурация по умолчанию для Firebird не оптимальна для нашей тестовой системы.
Настройка параметров в firebird.conf
Кэш страниц
Итак, чтобы улучшить производительность OLTP, мы решили попробовать архитектуры Classic и SuperClassic. Одним из ключевых параметров для Classic и SuperClassic является количество буферов страниц в кэше. В отличие от SuperServer, Classic и SuperClassic выделяют кэш страниц на каждое подключение.
Более подробно об архитектурах Firebird в 2.5 вы можете посмотреть в этой таблице: http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf
Существует простая формула для расчета использования памяти кэша страниц для разных архитектур Firebird:
-
- SuperServer - один кэш страниц на базу данных. Размер кэша страниц по умолчанию - 2048 страниц, рекомендуемое значение - 10000 буферов. В нашем случае кэш составлял 16k (размер страницы) x 10000 ~= 160 МБ. Это для всех подключений.
-
- Classic и SuperClassic - движок выделяет кэш страниц для каждого подключения. Размер по умолчанию - 75 страниц, то есть 16 КБ (размер страницы) x 75 = ~= 1,17 МБ для каждого подключения.
Очевидно, что размер кэша страниц следует увеличить, так как 75 страниц на подключение слишком мало. Ниже мы покажем результаты нескольких различных значений размера кэша страниц.
LockHashSlots
Внутри движок Firebird использует таблицу блокировок для запроса и получения блокировок внутренних объектов в базе данных, и для Classic и SuperClassic существует параметр LockHashSlots (значение по умолчанию - 1009). Его следует увеличивать при высокой нагрузке, чтобы уменьшить хэш-цепочки в таблице блокировок. Ну, «высокая нагрузка», похоже, относится к любому реальному многопользовательскому приложению, поэтому мы установили его на 30011 (для всех тестов).
LockMemSize
Параметр LockMemSize используется для установки начального размера таблицы блокировок (значение по умолчанию - 1048576). Движок может увеличивать размер таблицы по требованию. Однако увеличение таблицы блокировок дорого с точки зрения CPU и других ресурсов, поскольку выполняется через перераспределение памяти. Поэтому мы установили его на 7 МБ, чтобы сэкономить время и ресурсы CPU.
Тестовые запуски
Мы провели несколько тестовых запусков с различными значениями кэша страниц, и получили следующие результаты:
| Буферы страниц | Classic, тестовые баллы | SuperClassic, тестовые баллы |
|---|---|---|
| 256 | 299 | 372 |
| 512 | 371 | 359 |
| 768 | 362 | 386 |
| 1024 | 312 | 387 |
| 1500 | 390 | 392 |
| 2048 | 285 | 284 |
Таблица 1. Тестовые запуски для Classic и SuperClassic
Как видите, Classic и SuperClassic гораздо эффективнее, чем Firebird SuperServer для этой задачи: результаты тестов улучшились с 169 баллов до 300-400, что близко к результатам, которые мы получили для базы данных 30 ГБ!
Результаты лучше видны на следующем графике:
Рисунок 2. Результаты тестов для базы данных 1,7 терабайта
Вы можете видеть, что лучшая производительность (как для Classic, так и для SuperClassic) была при 1500 страницах на подключение, поэтому размер кэша страниц на подключение составил:
1500x16k ~= 23,4 МБ
При 2000 страницах на подключение производительность значительно снизилась. Похоже, что где-то около 1500-2000 страниц преимущество кэширования стало меньше, чем накладные расходы, вызванные взаимодействием таблиц блокировок между процессами для синхронизации страниц в кэшах каждого серверного процесса. Очевидно, что при большем количестве подключений это произойдет раньше, поэтому серверы Classic/SuperClassic обычно настраиваются с такими значениями, как 256-512 страниц.
Также наблюдается падение производительности Classic при кэше 768-1000 страниц - не уверены, почему это произошло.
Итоги
Наши эксперименты подтверждают, что производительность Firebird может быть увеличена при правильном выборе архитектуры Firebird (SuperServer, Classic или SuperClassic) и соответствующей настройке нескольких важных параметров для конкретной архитектуры.
В результате огромная база данных Firebird SQL размером 1,7 ТБ может работать на недорогом оборудовании с достаточно хорошей производительностью. В качестве практического результата этих тестов мы создали несколько файлов конфигурации для всех версий Firebird и всех архитектур. Конечно, они не настроены под конкретное приложение и/или оборудование, но они лучше, чем файлы конфигурации по умолчанию, которые рассчитаны на очень скромную нагрузку.
Полный набор оптимизированных файлов конфигурации Firebird: /ru/optimized-firebird-configuration/
Не стесняйтесь задавать любые вопросы: [email protected]
Что дальше?
Мы работаем над комплексным тестом, который сравнит производительность Firebird 2.5 и Firebird 3.0 с имитацией реальной нагрузки и большим количеством подключений. Оставайтесь с нами!