Погіршення продуктивності Firebird: тести, міфи та правда
Олексій Ковязін, 16 травня 2014
Ви можете завантажити цю статтю у форматі PDF.
Нещодавно в IBSurgeon ми провели серію тестів продуктивності з Firebird 2.5.2. Firebird 2.5.2 - найпопулярніша версія бази даних Firebird, і її користувачі часто мають питання, пов’язані з продуктивністю Firebird.
Одне з найважливіших питань щодо продуктивності бази даних - це її деградація. Багато користувачів стверджують, що їхні застосунки баз даних мають проблеми з продуктивністю при досягненні певного порогового значення: це може бути 3 ГБ, 5 ГБ, розмір оперативної пам’яті, 20 ГБ тощо. Найпоширеніше твердження: «розмір бази даних більший за розмір оперативної пам’яті»: коли розмір бази даних Firebird досягає розміру оперативної пам’яті, повідомляється, що вона стає дуже повільною… Чи це правда?
Ми вирішили провести серію тестів, щоб перевірити, чи існує така деградація продуктивності, пов’язана зі зростанням бази даних. Ми вирішили змоделювати зростання бази даних протягом життєвого циклу з однаковим навантаженням на тому самому обладнанні, і для цього провели 11 тестів з базами даних розміром від 9 ГБ до 30 ГБ:
Рисунок 1. Розміри баз даних для тестів
Тестове обладнання та конфігурація Firebird
Тестове обладнання мало такі ключові характеристики:
CPU AMD-FX8350, RAM 16 ГБ, SATA програмний RAID1 2x4Tb диски Seagate, операційна система Windows Server 2008R2 (2008R2 - 64-бітна).
Як бачите, це конфігурація нижнього рівня; її можна придбати менш ніж за 1000 доларів США на даний момент (травень 2014), і її можна вважати типовою конфігурацією нижнього рівня - можливо, за винятком великих SATA-дисків, але згідно зі звітом виробника, швидкість SATA-дисків 1 ТБ і 4 ТБ майже однакова.
Оскільки метою тесту було виміряти зміни продуктивності типової системи, ми використали Firebird (64-бітний) з архітектурою SuperServer, а не Classic, щоб повністю змоделювати ситуацію в малій компанії - вони використовують те, що було встановлено спочатку протягом років. Як відомо, SuperServer використовує лише 1 ядро CPU, тому, ймовірно, Classic або SuperClassic (які можуть використовувати всі ядра CPU) могли б показати кращі результати з точки зору продуктивності, але нашою метою не було налаштування продуктивності.
Однак ми налаштували firebird.conf з очевидними змінами, які ми рекомендуємо для всіх інсталяцій Firebird SuperServer: збільшили буфери сторінок до 10000 і тимчасовий простір для сортування.
Усі тестові бази даних були створені з розміром сторінки 16384, просто для узгодженості.
Тестування
Завантаження
Кожен тест містив 2 етапи: завантаження та симуляцію 20 терміналів, які виконують вставки, оновлення та видалення.
Етап завантаження виконується застосунком-завантажувачем (load.exe), який вставляє дані в кілька таблиць. Як ви можете бачити на рисунку 2, дані завантажуються з різною швидкістю; вона варіюється від ~35 МБ/сек до 1 МБ/сек.
Рисунок 2. Швидкість завантаження бази даних (червоний графік)
Це пов’язано з дизайном застосунку-завантажувача, а не з Firebird: завантажувач швидко вставляє 70% бази даних, а потім повільно заповнює решту даних, і це повторюється для баз даних усіх розмірів. Для нас важливо, що завантажувач виконує однакові операції, тому ми можемо використовувати його середню швидкість для вимірювання швидкості завантаження.
Важливо зазначити, що завантажувач вставляє лише дані, а індекси створюються після завершення завантаження.
Погляньмо на таблицю з результатами етапу завантаження для 11 баз даних між 9 і 30 ГБ:
| # | розмір бази даних, ГБ | час завантаження, сек | швидкість завантаження SATA, МБ/сек |
|---|---|---|---|
| 1 | 9,04 | 2535 | 3,65166075 |
| 2 | 10,80 | 3197 | 3,45924304 |
| 3 | 13,00 | 4057 | 3,281242297 |
| 4 | 15,50 | 4698 | 3,378458919 |
| 5 | 17,30 | 5455 | 3,24751604 |
| 6 | 19,90 | 6037 | 3,375451383 |
| 7 | 21,60 | 6473 | 3,417024564 |
| 8 | 24,20 | 7539 | 3,287014193 |
| 9 | 26,00 | 7779 | 3,422547885 |
| 10 | 28,60 | 8851 | 3,308823862 |
| 11 | 30,30 | 9266 | 3,348499892 |
Рисунок 3. Час і швидкість завантаження
Або краще показати на графіку на рисунку 4:
Рисунок 4. Результати тесту: швидкість завантаження.
Як бачите, графік досить стабільний, і середня швидкість процесу завантаження коливається близько 3,3-3,4 МБ/сек. Також немає ознак зменшення швидкості завантаження, коли розмір бази даних перевищує розмір оперативної пам’яті (після бази даних №5, розміром 17,3 ГБ).
Продуктивність
Отже, час завантаження виглядає досить обнадійливо, а що щодо фактичних результатів продуктивності?
Перш ніж перейти до результатів продуктивності, коротко розглянемо процес симуляції.
Симуляція запускає 20 потоків, і кожен із них випадково виконує кілька бізнес-операцій: створення нового замовлення, обробка платежу, підрахунок товарів на складі, обробка доставки замовлення тощо (детальніше можна переглянути SQL-тексти фактичних збережених процедур). Як бачите, це звичайний набір бізнес-операцій абстрактного застосунку інвентаризації/продажів.
Тестовий застосунок вимірює кількість бізнес-операцій за секунду та звітує про середнє значення. Звичайно, це штучний параметр, але він достатньо хороший для порівняння.
Результати тесту продуктивності:
| # | розмір бази даних, ГБ | продуктивність на SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
Рисунок 5. Таблиця з результатами тесту продуктивності.
Або краще переглянути результати у графічному представленні:
Рисунок 6. Графік результатів продуктивності
Як бачите, спостерігається повільна деградація продуктивності зі зростанням розміру бази даних - чим більша база даних, тим повільніше вона працює (на тому самому обладнанні). Також немає великого падіння продуктивності, коли розмір бази даних перевищує розмір оперативної пам’яті. Зростання бази даних з 9 ГБ до 30 ГБ призводить до приблизно 20% втрати продуктивності.
Бази даних Firebird на 30 ГБ зараз всюди, і вони ростуть і ростуть з часом. Однак що станеться з продуктивністю бази даних, коли вона стане ще більшою? Ми маємо на увазі - НАБАГАТО БІЛЬШОЮ! Що станеться з продуктивністю, коли база даних стане ДІЙСНО ВЕЛИКОЮ?
Містер Біг
Щоб відповісти на це питання, ми вирішили зазирнути в самий кінець тестової таблиці та провести тест з базою даних 1,7 ТБ (1813 ГБ), на тому самому обладнанні, з тими самими налаштуваннями.
Завантаження
Отже, ми створили таку базу даних:
Рисунок 7. Розмір бази даних - тепер з базою даних 1813 ГБ
Завантаження зайняло 566448 секунд - 157 годин, 6,55 днів. Це довгий час, але середня швидкість завантаження була… 3,28 МБ/сек!
| # | розмір бази даних, ГБ | час завантаження, сек | швидкість завантаження SATA, МБ/сек |
|---|---|---|---|
| 12 | 1813,969025 | 566448 | 3,279214122 |
Рисунок 8. Час і швидкість завантаження для бази даних Firebird 1,7 ТБ
На графіку це виглядає дуже добре: остання точка (#12). Отже, Firebird показує дуже хороші результати своїх алгоритмів вставки.
Рисунок 9. Швидкість завантаження - точка №12 для бази даних Firebird 1,7 ТБ
Продуктивність Містера Біга
Потім ми запустили той самий тест продуктивності - рядок 12 для бази даних 1,7 ТБ.
| # | розмір бази даних, ГБ | продуктивність на SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
| 12 | 1813,969025 | 169,33 |
Рисунок 10. Результати тесту продуктивності - рядок 12 для бази даних 1,7 ТБ
І на графіку:
Рисунок 11. Продуктивність, точка #12 для бази даних 1.7Tb
Результат підтверджує, що у Firebird спостерігається повільне та стабільне погіршення продуктивності - коли розмір бази даних зріс у 60 разів (з 30Gb до 1813Gb), втрата продуктивності становила 2.4 рази (з 407 до 169 балів).
Це не часта ситуація, коли база даних (на тому ж недорогому обладнанні) зростає з 30Gb до 1.7Tb, але Firebird працюватиме навіть у такій ситуації.
Велика база даних детально
Щоб краще зрозуміти базу даних 1.7Tb, ми зібрали статистику для бази даних Mr.Big та проаналізували її в IBAnalyst:
Рисунок 12. Таблиці бази даних 1.7Tb в IBAnalyst
Як ви можете бачити, є 2 великі таблиці - ORDER_LINE (~600 Gb) з 6.3 мільярдами записів та STOCK (~680 Gb) з 2.1 мільярдами записів.
І для цих таблиць є 2 індекси з глибиною = 4 - це означає, що кожен запит виконує 4 читання сторінок індексу перед фактичним читанням даних. Індекс ORDER_LINE_PK має розмір 50Gb.
Рисунок 13. Індекси бази даних Firebird 1.7Tb
Незважаючи на величезну кількість записів, статистика бази даних виглядає добре, тому не дивно, що Firebird показує досить хороші результати навіть для великої бази даних на недорогому обладнанні.
Тестування Firebird з SSD-диском
Після завершення серії тестів Firebird на недорогому обладнанні ми вирішили перевірити, якими будуть результати на іншому кінці технології зберігання даних, і встановили SSD-диск на той самий сервер.
Ми встановили SSD-диск Plextor PX-256M M5 Pro та запустили ту саму серію тестів (крім бази даних 1.7Tb) з тими самими налаштуваннями. Результати були додані до графіків із SATA-пристроями, дивіться їх нижче.
Завантаження
Як ви можете бачити, час завантаження на SSD такий самий, як на SATA. Це очікуваний результат: швидкість послідовних операцій запису майже однакова на SATA та SSD-дисках.
Рисунок 14. Завантаження на SSD та SATA
Продуктивність
Дивіться результати продуктивності:
Рисунок 15. Продуктивність на SSD та SATA
Як ви можете бачити, продуктивність з операціями випадкового введення/виведення показує ~8x кращі результати для SSD-диска. Ми знали з нашого досвіду з базами даних клієнтів, що SSD на 30-50% швидший у реальних застосунках, але збільшення у 8 разів є дуже високим.
Однак цей тест є штучним і спеціально розробленим для імітації високого навантаження OLTP-операцій, з багатьма оновленнями/видаленнями, але без великих вибірок. Звичайний додаток з базою даних не працює в такому режимі весь час. Це пояснює, чому SSD показує такі високі результати в цьому конкретному випадку.
Підсумок
Отже, що ми дізналися з цих тестів?
Перш за все - продуктивність Firebird не має значних падінь, пов’язаних з якимось обмеженням розміру. На тому самому обладнанні продуктивність буде повільно знижуватися зі зростанням розміру бази даних. Таке зниження продуктивності можна компенсувати налаштуванням конфігурації Firebird або розумним оновленням обладнання.
Це гарне місце, щоб згадати, що IBSurgeon пропонує послугу оптимізації продуктивності Firebird - використовуючи експериментальні дані, зібрані з таких тестів, ми можемо значно підвищити продуктивність баз даних Firebird та InterBase.
По-друге, ми знали, що навіть дуже великі бази даних Firebird (1.7 терабайта) працюватимуть на недорогому обладнанні зі значними, але прийнятними втратами продуктивності.
І по-третє, SSD дійсно хороший для OLTP-застосунків. Ймовірно, це найдешевший спосіб підвищити продуктивність бази даних на даний момент. Звичайно, використання SSD не виправить проблеми з поганими планами запитів та неефективними індексами, але може підвищити продуктивність загалом.
Далі буде: Більше деталей про базу даних Firebird 1.7 Терабайта.