Налаштування бази даних Firebird SQL об'ємом 1,7 терабайта
Олексій Ковязін, 14 липня 2014
Як ви пам’ятаєте з наших попередніх статей, ми досліджували міфи про деградацію продуктивності Firebird ( /uk/articles/firebird-performance-degradation-tests-myths-and-truth/), де створили кілька баз даних від 9 ГБ до 30 ГБ, а також протестували дуже велику базу даних Firebird (1,7 терабайта) (/uk/articles/more-details-about-1-7-terabyte-firebird-sql-database/).
Усі тести проводилися на тому самому обладнанні, яке є досить бюджетною конфігурацією: процесор AMD-FX8350, 16 ГБ оперативної пам’яті, програмний RAID1 SATA 2x4 ТБ на жорстких дисках Seagate, операційна система Windows Server 2008R2 (2008R2 - 64-бітна), і з тією самою конфігурацією Firebird: це був Firebird 2.5.2 64-бітний, SuperServer, зі збільшеними буферами сторінок і TempCacheSize. Ви можете безкоштовно завантажити цей файл конфігурації SuperServer за цим посиланням: /uk/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, які підтримують багатопотокову обробку та використовують кілька ядер процесора (у процесорі 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). Рушій може збільшувати розмір таблиці за потреби. Однак збільшення таблиці блокувань є дорогим з точки зору процесора та інших ресурсів, оскільки виконується через перепризначення пам’яті. Тому ми встановили його на 7 МБ, щоб заощадити трохи часу та ресурсів процесора.
Тестові запуски
Ми провели кілька тестових запусків із різними значеннями кешу сторінок, і отримали такі результати:
| Буфери сторінок | 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: /uk/optimized-firebird-configuration/
Не соромтеся ставити будь-які запитання: [email protected]
Що далі?
Ми працюємо над комплексним тестом, який порівняє продуктивність Firebird 2.5 і Firebird 3.0 із реалістичним моделюванням навантаження та великою кількістю з’єднань. Слідкуйте за оновленнями!