Посібник з апаратного забезпечення Firebird

від Alexey Kovyazin, останнє оновлення: 30 листопада 2015 року

Ви часто можете побачити наступне питання в групах технічної підтримки Firebird: «Яке апаратне забезпечення обрати для СУБД Firebird?». Ця тема залишається постійно популярною, оскільки вимоги до апаратного забезпечення відрізняються залежно від завдань, а саме апаратне забезпечення змінюється з часом.

Ми вирішили написати цей посібник, щоб надати необхідні знання кожному, хто хоче обрати справді ефективне апаратне забезпечення для своєї бази даних Firebird. Для цього вам доведеться вивчити деякі базові деталі про те, як працюють Firebird, операційна система і, звичайно, апаратне забезпечення.

Трохи теорії

Щоб з’ясувати, яке апаратне забезпечення найкраще підійде для вашої бази даних Firebird, ми маємо зрозуміти, як Firebird використовує свої компоненти: CPU, RAM, HDD/SSD і як ці компоненти взаємодіють з операційною системою (наприклад, з файловим кешем).

Функціональні модулі сервера Firebird

Перш за все, ми розглянемо функціональні модулі Firebird за допомогою рисунка 1:

Рисунок 1. Модулі Firebird

Firebird включає такі основні функціональні модулі:

Об’єкти метаданих: представлення, таблиці, індекси, тригери, збережені процедури та інші об’єкти бази даних. Об’єкти метаданих розташовані в адресному просторі процесу Firebird (це може бути fbserver, fb_inet_server або firebird.exe).
Кеш сторінкових буферів містить сторінки бази даних, прочитані з диска, і розташований в адресному просторі серверного процесу. Механізм кешування сторінок досить складний, тому ми лише зазначимо, що Firebird кешує найчастіше використовувані сторінки бази даних.
Firebird сортує записи в пам’яті (в адресному просторі серверного процесу), доки обсяг пам’яті, використаної для всіх одночасних операцій сортування, не досягне межі, встановленої параметром TempCacheLimit (firebird.conf). Після перевищення цієї межі у папці з тимчасовими файлами створюється тимчасовий файл (з відповідним прапорцем операційної системи), який використовується для сортування. Якщо в системі є вільна RAM, файл сортування буде закешований операційною системою, і сортування виконуватиметься в пам’яті.
Глобальні тимчасові таблиці (GTT) створюються як тимчасові файли в операційній системі. Якщо операційна система має вільну пам’ять, операції з GTT виконуються в RAM.

Основні операції з апаратним забезпеченням

Розглянемо, як функціональні модулі Firebird взаємодіють з апаратними компонентами під час операцій, що виконуються в процесі роботи з базами даних.

Після запуску Firebird серверний процес займає мінімальний обсяг RAM (кілька мегабайт) і не виконує жодних інтенсивних операцій з CPU або RAM.

Коли встановлюється з’єднання з базою даних, сервер починає читати її метадані та створювати відповідні об’єкти в пам’яті, що призводить до того, що процес займає тим більше ресурсів, чим більше таблиць, індексів, тригерів та інших метаданих використовується. Використання пам’яті зростає, але CPU на цьому етапі практично не використовується.

Коли клієнт починає виконувати SQL-запити (включно зі збереженими процедурами), сервер виконує відповідні операції з використанням апаратного забезпечення. Можна виділити такі основні операції, що передбачають взаємодію з апаратним забезпеченням:

читання сторінок бази даних з жорсткого диска,
запис сторінок бази даних на жорсткий диск,
читання сторінок бази даних з кешу,
запис сторінок бази даних у кеш,
читання даних з глобальних тимчасових таблиць і запис даних у них,
обробка SQL-запитів (наприклад, JOIN),
сортування записів у результуючих наборах.

Кожна з цих операцій потребує певної кількості системних ресурсів. У таблиці нижче показано споживання ресурсів в інтенсивних одиницях (1 означає найменш інтенсивне, 10 - найбільш інтенсивне):


	Читання сторінки з диска	Запис сторінки на диск	Читання сторінки з кешу сторінкових буферів	Запис сторінки в кеш сторінкових буферів	Читання з GTT	Запис у GTT	Сортування записів	Обробка SQL-запитів
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
Дисковий I/O	10	10	1	1	1	1	1	1

Як бачите, найбільш ресурсоємними операціями є ті, що пов’язані з доступом до диска, оскільки диски залишаються найповільнішим апаратним компонентом, незважаючи на прогрес останніх років, пов’язаний із SSD.

Це призводить до одного зі способів оптимізації продуктивності, який повністю пов’язаний з апаратним забезпеченням, - перенести всі операції читання-запису в RAM. Але зауважте, що підхід зі збільшенням сторінкового кешу не працює. Ми детально розглянемо це питання в розділі про RAM.

Одночасно виконувані операції

Зазвичай необхідно обирати апаратне забезпечення для сервера, який обслуговуватиме багато клієнтів, тому дуже важливо зрозуміти, як реалізовано паралелізм операцій.

З точки зору апаратних компонентів ми можемо говорити про паралельне використання CPU, диска та RAM. Сучасні CPU мають кілька ядер, які можуть виконувати набори інструкцій паралельно, тому сервер СУБД розподіляє операції між ядрами, що означає висновок: чим більше ядер має CPU, тим більше клієнтів зможуть працювати на цьому сервері.

З точки зору дисків усе не так просто. Коли традиційні жорсткі диски (HDD) читають інформацію, вони фізично переміщують головку над магнітним матеріалом із певною кінцевою швидкістю. База даних може бути досить великою, наприклад, 3 терабайти, і якщо SQL-запити від клієнтів паралельно звертаються до даних, розташованих у різних областях диска, головка диска стрибатиме між різними областями, що серйозно сповільнить операції читання та запису. Це значно збільшить чергу диска, тоді як решта ресурсів (CPU, RAM) простоюватимуть. Звичайно, кеш диска (кеш HDD або RAID-контролера) певною мірою компенсує це уповільнення, але цього недостатньо.

На відміну від традиційних HDD, твердотільні накопичувачі (SSD) набагато менш схильні до деградації продуктивності у разі паралельного доступу до даних. Перевага SSD особливо очевидна під час паралельного запису даних - наші тести показують, що SSD у 7 разів швидший за SATA-диск (посилання!). Однак SSD мають деякі проблеми, які необхідно враховувати під час їх використання (див. Вибір дисків), щоб уникнути уповільнень, передчасних поломок і втрати даних.

Операції з RAM виконуються дуже швидко на сучасних комп’ютерах, вони практично обмежені лише пропускною здатністю шини даних, тому ці операції не стають вузьким місцем, навіть якщо є багато паралельних SQL-запитів.

Потоки даних

Під час виконання SQL-запитів Firebird читає та записує багато даних, передає їх між функціональними модулями та відповідними апаратними компонентами. Щоб виявити можливі вузькі місця, нам потрібно зрозуміти, як здійснюється обмін даними. Рисунок 2 нижче допоможе нам у цьому:

Рисунок 2. Потоки даних між RAM і постійним сховищем

Очевидно, що передача даних із постійного сховища в RAM і назад є найбільш трудомісткою операцією. Вона створює два потоки даних: читання/запис сторінок даних із файлів бази даних і читання/запис файлів сортування. Оскільки файлів сортування може бути кілька і вони можуть бути досить великими, вони можуть створювати досить велике навантаження на диски, тому бажано спрямовувати ці потоки введення/виведення на різні диски.

Резервне копіювання

Firebird пропонує два методи резервного копіювання: перевірене резервне копіювання за допомогою утиліти gbak і неперевірене інкрементальне резервне копіювання за допомогою утиліти nbackup.

Ми рекомендуємо комбінувати ці методи резервного копіювання: запускати nbackup часто (наприклад, щогодини, щодня та щотижня) і створювати перевірену резервну копію щоночі за допомогою gbak.

Який би метод резервного копіювання ви не використовували, файл бази даних читається (повністю або частково), а резервна копія (повна або інкрементальна) записується. Операції запису виконуються послідовно під час процесу резервного копіювання, що означає, що звичайні недорогі жорсткі диски з інтерфейсом SATA (HDD SATA) будуть хорошими для резервного копіювання, оскільки вони послідовно записують досить швидко.

Вибір відповідного обладнання

Тепер, коли ми маємо уявлення про те, як Firebird взаємодіє з апаратним забезпеченням, варто зупинитися на факторах, що впливають на вибір кожного конкретного компонента та його характеристик.

Іноді фактична статистика конкретної бази даних суттєво впливає на вибір апаратних компонентів, тому ми використаємо інструменти з HQbird (професійного дистрибутивного пакету Firebird від IBSurgeon), щоб отримати цю статистику. Ви можете завантажити пробну версію HQbird за адресою http://hqbird.com/en/hqbird/.

Процесор

Обираючи процесор, слід враховувати три речі:

Які запити переважають у застосунку,
Кількість активних з’єднань із базою даних у середньому та при пікових навантаженнях,
Версію та архітектуру Firebird.

Які запити переважають у застосунку?

Firebird завжди виконує один запит на одному ядрі, тому складні та погано оптимізовані запити можуть використовувати одне ядро до 100%, витісняючи інші запити на менш завантажені ядра. І чим більше ядер, тим менша ймовірність того, що весь процесор буде використано повністю і що користувачі помітять погіршення продуктивності застосунку.

Якщо застосунок переважно виконує прості короткі SQL-запити, усі запити добре оптимізовані та не генеруються ad hoc запити (наприклад, для звітів), процесор не буде вузьким місцем для продуктивності, і ви можете обрати недорогий процесор із меншою кількістю ядер.

Якщо застосунок містить генератор звітів або багато повільних запитів, що повертають великий обсяг даних, вам потрібен процесор із більшою кількістю ядер.

Кількість активних з’єднань із базою даних у середньому та при пікових навантаженнях

Кількість з’єднань (активних користувачів) також впливає на вибір процесора. На жаль, навіть розробники застосунків не мають точного уявлення про те, скільки з’єднань, запитів і транзакцій є активними в конкретний момент. Щоб отримати точнішу інформацію про це, ми рекомендуємо використовувати інструмент MON$ Logger з HQbird і зробити кілька знімків під час його роботи, де ви побачите, скільки з’єднань фактично встановлено.

Рисунок 3. MON$ Logger: кількість з’єднань

Наприклад, тут видно, що кількість з’єднань становить 296. Очевидно, що в цьому випадку використовувати чотирьохядерний процесор було б надто оптимістично, тоді як рішення з 24 ядрами буде цілком прийнятним. Також бажано підрахувати кількість одночасно виконуваних запитів, оскільки з’єднання можуть бути простоюючими без жодних виконуваних SQL-запитів.

Ви можете використовувати співвідношення від 10 до 30 з’єднань на 1 ядро для приблизної оцінки необхідної кількості ядер у вашому процесорі. 10 з’єднань на ядро - для застосунку з переважно складними та повільними запитами, 30 з’єднань на ядро - для застосунку з переважно простими добре оптимізованими запитами.

Версія та архітектура Firebird

Якщо ви використовуєте Firebird версії 2.5, зверніть увагу, що слід використовувати архітектуру Classic або SuperClassic, щоб мати можливість розподіляти обробку між кількома ядрами. У версії 2.5 архітектура SuperServer може використовувати лише одне ядро для однієї бази даних, тому її не слід використовувати в системах, що споживають багато ресурсів.

У Firebird версії 3.0 SuperServer, Classic та SuperClassic використовують можливості багатоядерних процесорів. Firebird 3.0 SuperServer показує найкращу продуктивність.

Оперативна пам’ять

Обираючи оперативну пам’ять, слід звернути увагу на дві речі:

модуль пам’яті повинен мати код виправлення помилок (ECC RAM)
обсяг оперативної пам’яті має бути правильно розрахований

ECC RAM

ECC RAM значно зменшує кількість помилок, що виникають під час роботи з пам’яттю, і її наполегливо рекомендується використовувати в промислових системах.

Розрахунок необхідного обсягу оперативної пам’яті

Щоб розрахувати обсяг пам’яті, нам доведеться розглянути особливості різних архітектур Firebird. Firebird 2.5 Classic та Firebird 3.0 Classic запускають окремий процес для обслуговування кожного з’єднання, SuperClassic запускає окремий потік для кожного з’єднання, але практично з такою ж структурою споживання пам’яті - кожне з’єднання має власний незалежний кеш сторінок.

Firebird SuperServer запускає один процес з одним кешем сторінок для всіх з’єднань.

Таким чином, на загальне споживання пам’яті впливають такі параметри:

Кількість з’єднань
Розмір сторінки бази даних
Розмір метаданих (пропорційний кількості таблиць, тригерів, збережених процедур тощо; не регулюється; визначається фізичним використанням)
Для Classic та SuperClassic - на кожне з’єднання
Для SuperServer - на кожен екземпляр відкритої бази даних
Розмір кешу сторінок (визначається параметрами в заголовку бази даних або у firebird.conf, або у властивостях конкретного з’єднання)
Для Classic та SuperClassic - на кожне з’єднання
Для SuperServer - на кожен екземпляр відкритої бази даних
Розмір кешу сортування (визначається параметром у firebird.conf). Зверніть увагу, що пам’ять для сортування виділяється не одразу, а в міру необхідності.
Для Classic - на кожне з’єднання
Для SuperServer та SuperClassic - на процес (тобто один кеш сортування)
Для Classic/SuperClassic - розмір таблиці блокувань (зазвичай він малий, тому ми залишимо його поза розрахунком).

Компанія IBSurgeon провела кілька тестів і отримала набір оптимальних значень для кількості сторінок у кеші сторінок Firebird:

Classic/SuperClassic - від 256 до 2000 сторінок
SuperServer 2.5 - 10000 сторінок
SuperServer 3.0 - 100000 сторінок

На основі цих тестів ми створили оптимізовані файли конфігурації Firebird для серверів з 4-6 ГБ пам’яті. Ви можете завантажити їх тут: /uk/optimized-firebird-configuration/

Формули для розрахунку необхідного обсягу оперативної пам’яті

Нижче наведено формули для оцінки приблизного обсягу пам’яті, який знадобиться Firebird. Фактичне споживання пам’яті може відрізнятися, оскільки ця оцінка не враховує обсяг пам’яті, необхідний для метаданих, бітових масок індексів тощо, що може збільшити споживання пам’яті. Однак також передбачається, що пам’ять для сортування буде використовуватися повністю у всіх з’єднаннях, що зазвичай не так.

Коли ваша база даних уже використовується, ви можете подивитися на середній обсяг пам’яті, який використовує процес Firebird (за допомогою TaskManager або ProcessExplorer).

Оцінка для Classic:

Кількість з’єднань * ( (Кількість сторінок у кеші * Розмір сторінки) + Розмір кешу сортування )

Приклад для Classic: припустимо, ми очікуємо 100 активних користувачів, розмір сторінки бази даних встановлено на 8 КБ, кількість сторінок у кеші сторінок встановлено на 256, розмір кешу сортування збільшено з 8 МБ (типове значення для Classic та SuperClassic) до 64 МБ:

((256.8 КБ)+64) = 6600 МБ

Оцінка для SuperClassic:

Кількість з’єднань * (Кількість сторінок у кеші * Розмір сторінки) + Розмір кешу сортування

Приклад для SuperClassic: 100 користувачів, розмір сторінки бази даних 8 КБ, кількість сторінок у кеші сторінок 256, розмір кешу сортування 1024 МБ

100.(256.8 КБ) + 1024 МБ = 2024 МБ

Оцінка для SuperServer:

(Кількість сторінок у кеші * Розмір сторінки) + Розмір кешу сортування

Приклад для SuperServer (Firebird 2.5): 1 база даних, 100 користувачів, розмір сторінки бази даних 8 КБ, кількість сторінок у кеші сторінок 10000, розмір кешу сортування 1024 МБ:

(10000.8 КБ) + 1024 = 1102 МБ

Приклад для SuperServer (Firebird 3.0): 1 база даних, 100 користувачів, розмір сторінки бази даних 8 КБ, кількість сторінок у кеші сторінок 100000, розмір кешу сортування 1024 МБ:

(100000.8 КБ) + 1024 = 1805 МБ

«Надмірна пам’ять»

Firebird часто звинувачують у неефективному використанні пам’яті - коли запущений процес сервера споживає невеликий обсяг оперативної пам’яті, а решта пам’яті залишається нібито невикористаною.

Насправді це не так. Цей висновок ґрунтується на нерозумінні того, як працює механізм кешування Firebird, та на недосконалості інструментів моніторингу операційної системи.

Перш за все, ви маєте чітко розуміти, що Firebird інтенсивно використовує файловий кеш операційної системи. Коли сторінка завантажується в кеш сторінок Firebird, вона проходить через файловий кеш операційної системи. Коли Firebird вивантажує сторінку зі свого кешу сторінок, операційна система продовжує утримувати цей фрагмент бази даних у своїй оперативній пам’яті, якщо в неї залишилося достатньо вільної пам’яті.

Рисунок 4. Рівні кешу: Firebird, ОС та сховище

Однак, якщо просто подивитися на це, операційна система не показує пам’ять, виділену під файловий кеш, як використану. Наприклад, ось типова ситуація розподілу пам’яті під час роботи сервера Firebird, як показано в Диспетчері завдань:

Рисунок 5. Диспетчер завдань не показує використання файлового кешу

Виглядає так, ніби використано лише 6,3 ГБ з 16 ГБ.

Однак, якщо ви використовуєте інструмент RAMMap (від SysInternals від Microsoft), усе виглядає набагато логічніше:

Рисунок 6. RAMMap показує деталі використання пам’яті: відображені файли - це закешовані бази даних

Файли бази даних (dbw350.fb252x64.fdb та dbw250.fb252x64.fdb) кешуються операційною системою та займають всю пам’ять, яку Диспетчер завдань оголошує вільною:

Рисунок 7. RAMMap: деталі використання файлового кешу

Звідси ми робимо висновок, що операційна система ефективно використовує всю доступну пам’ять для кешування бази даних, аж до повного завантаження бази даних у пам’ять.

Підсистема дисків

Правильна конфігурація підсистеми дисків відіграє важливу роль у виборі та налаштуванні обладнання для Firebird, оскільки будь-які помилки на цьому етапі призведуть до серйозних збоїв, які важко виправити.

Окремі диски для всього

Щоб зменшити конкуренцію за введення/виведення даних між операціями з файлом бази даних та зменшити ймовірність одночасної втрати бази даних і резервної копії, рекомендується мати три різні диски (або RAID-масиви): один для бази даних, один для тимчасових файлів та один для створення та зберігання резервних копій.

Коли ми говоримо «окремі диски», це означає, що потоки даних мають проходити через різні канали введення/виведення. Якщо ви створите три логічні диски на одному фізичному диску, підвищення продуктивності не буде. Однак, якщо ви організуєте три логічні диски на пристрої зберігання даних, оснащеному багатоканальними контролерами, продуктивність, найімовірніше, зросте, оскільки пристрій може розподіляти потоки даних між контролерами. Іноді кажуть, що виділення окремого диска для зберігання файлів операційної системи та файлу підкачки операційної системи підвищує продуктивність.

SSD для бази даних

SSD - найкращий вибір для роботи з базою даних, оскільки вони забезпечують чудове масштабування під час паралельного введення/виведення. Обов’язково використовуйте корпоративні диски зі збільшеною кількістю циклів читання/запису, інакше дуже ймовірно, що ви втратите дані через вихід з ладу SSD.

Деякий час тому SSD були схильні до підвищеного зношування, якщо на диску залишалося мало вільного місця (менше 30%). Простіше кажучи, кожна зміна на SSD записується в нову вільну комірку, тому нестача вільного місця призводила до підвищеного зношування комірок, що залишалися вільними, і до скорочення терміну служби диска.

Виробники сучасних SSD-контролерів заявляють, що цю проблему вирішено шляхом превентивного переміщення статичних даних, і тепер зношування комірок більш-менш вирівняне. Однак точні специфікації та алгоритми роботи SSD тримаються виробниками в секреті, тому ми все одно рекомендуємо залишати 30% простору на SSD вільним, а також зменшити очікуваний термін служби та планувати заміну не рідше ніж раз на три роки.

Припустимо, розмір вашої бази даних наразі становить 100 ГБ, і вона зростає на 1 ГБ на місяць. У цьому випадку не варто купувати SSD мінімального розміру (120 ГБ), а краще обрати наступний пристрій у лінійці продуктів - 250 ГБ. Водночас купівля SSD на 512 гігабайт буде марною тратою грошей, оскільки диск бажано замінити через три роки.

Найкраща практика - виділити SSD виключно для роботи з базою даних, оскільки будь-які операції введення/виведення скорочують термін служби дисків.

Диск для тимчасових файлів

Оскільки тимчасові файли з’являються на диску лише тоді, коли недостатньо оперативної пам’яті, найкращий спосіб - звичайно ж, взагалі уникнути цієї ситуації. Оцінити кількість і розмір тимчасових файлів у виробничій системі можна лише шляхом моніторингу папки з тимчасовими файлами. FBDataGuard із дистрибутива HQbird виконує такий моніторинг. Щойно ви дізнаєтеся, скільки тимчасових файлів сортування створюється на диску та коли вони створюються, ви зможете збільшити обсяг оперативної пам’яті та змінити конфігурацію у firebird.conf.

У будь-якому разі Firebird вимагає, щоб ви вказали папку, де зберігатимуться тимчасові файли. Зазвичай значення за замовчуванням залишають без змін, тобто використовується системна папка операційної системи для тимчасових файлів. Якщо вільної оперативної пам’яті достатньо, це хороший вибір.

Однак є ще одне важливе питання щодо розташування тимчасових файлів на диску - це створення індексів під час відновлення перевіреної резервної копії (створеної за допомогою утиліти gbak). Коли створюється індекс, також створюється тимчасовий файл, що містить усі ключі цього індексу. Якщо база даних досить велика, розмір індексу для деякої великої таблиці також може бути досить великим. Наприклад, індекс найбільшої таблиці, що містить 3,2 мільярда записів у базі даних об’ємом 1 терабайт, становить 29 ГБ, але для створення цього індексу знадобилося 180 ГБ вільного простору:

Щоб запобігти нестачі вільного місця на системному диску, можна вказати ще один диск як додатковий резервний простір у firebird.conf:

TempDirectories =C:\temp; H:\Temp

Якщо на першому диску немає місця, Firebird продовжить використовувати другий диск для тимчасових файлів і так далі.

HDD для резервних копій

Звичайних HDD з інтерфейсом SATA або nSAS буде достатньо для створення та зберігання резервних копій. Вони забезпечують швидкі послідовні операції запису та читання для файлів резервних копій і достатньо дешеві, щоб не економити на їхньому розмірі та зберігати кілька резервних копій.

Диски для резервних копій завжди повинні мати додатковий вільний простір: розмір останньої резервної копії + 10%. У цьому випадку можна створити свіжу резервну копію, переконатися, що процес резервного копіювання успішно завершено (цей процес може тривати кілька годин для бази даних розміром у кілька терабайт), і лише після цього видалити попередню резервну копію.

Якщо ви видалите попередню резервну копію до створення нової, можливо, що нова резервна копія не буде створена, тоді як стара вже буде видалена, а база даних буде пошкоджена, наприклад, через вихід з ладу диска.

Якщо ви використовуєте рекомендований вище метод резервного копіювання (комбінація інкрементного трирівневого резервного копіювання та перевіреної резервної копії раз на день із зберіганням лише однієї останньої копії), використовуйте таку формулу для розрахунку мінімального простору для резервних копій:

Розмір_бази_даних*3+0.2.Розмір_бази_даних

Розглянемо такий приклад розрахунку простору, необхідного для резервних копій:

Припустимо, у нас є база даних об’ємом 100 ГБ, для якої ми зберігаємо трирівневе інкрементне резервне копіювання (тиждень-день-година - по одній копії) та одну копію щоденної перевіреної резервної копії. У цьому випадку резервні копії займуть такий простір:

Nbackup_level_0.weekly - 100 ГБ
Nbackup_level_1.daily - 5 ГБ (приблизно)
Nbackup_level_2.hourly - 200 МБ (приблизно)
Щоденна перевірена резервна копія - 100 ГБ (приблизно)
Плюс потрібно зарезервувати 110 ГБ, щоб мати можливість створити наступну резервну копію.

Разом - 316 ГБ.

! розмір інкрементного файлу першого рівня або вище залежить від кількості сторінок, змінених з моменту останнього запуску nbackup. Розмір цих файлів можна визначити лише експериментально, оскільки обсяг змін у базі даних залежить від застосунків.

Звісно, оцінка простору для резервної копії має враховувати можливе аномальне збільшення розміру бази даних і відповідно збільшувати обсяг вільного простору, інакше процес резервного копіювання може бути несподівано перерваний через брак місця.

Звісно, розумні інструменти резервного копіювання (FBDataGuard від HQbird) помітять брак простору для резервних копій і надішлють відповідне повідомлення адміністратору.

HDD для бази даних

SSD може виявитися занадто дорогим рішенням, або база даних може бути занадто великою, і вам доведеться використовувати менш дорогі методи. У цьому випадку слід використовувати HDD з інтерфейсом SAS. Якщо це неможливо, використовуйте диски SATA з інтерфейсом nSAS або найдешевший варіант - звичайні диски SATA.

Щоб підвищити швидкість (а також надійність - див. нижче) жорстких дисків, їх слід об’єднати в RAID10. RAID10 - це комбінація дзеркальних (RAID1) і смугових (RAID0) блоків. Хороший і правильно налаштований RAID-контролер з великим кешем є хорошою альтернативою SSD.

Надійність і RAID

Звісно, необхідно підвищити надійність дискової підсистеми, об’єднавши диски в RAID у всіх вищезгаданих варіантах (крім диска, призначеного виключно для тимчасових файлів).

• Для SSD переконайтеся, що ви використовуєте RAID1 - тобто два дзеркальні диски, на які одночасно записуються зміни, що значно зменшує шанси втратити всі дані. RAID10, що складається з SSD, швидше за все, буде надмірним, оскільки шина RAID обмежить пропускну здатність. Наприклад, інтерфейс 6 Гбіт/с має пропускну здатність 600 мегабайт на секунду, тоді як сучасні окремі SSD вже досягли цієї швидкості. Таким чином, ми отримаємо той самий ліміт 600 МБ/с для RAID10.

Хіба що ви можете використовувати PCI Express 3.0 для об’єднання SSD у RAID10, оскільки пропускна здатність цієї шини вже становить 16 гігабіт на секунду і вище.

• Якщо ви використовуєте HDD для резервного копіювання, достатньо RAID1, який забезпечить безпеку резервних копій і прийнятну швидкість читання та запису.

• HDD, що використовуються для бази даних, слід об’єднати в RAID10 (щонайменше 4 диски), що забезпечує оптимальне поєднання вартості, надійності та продуктивності. Деякі користувачі також використовують RAID5, жертвуючи продуктивністю заради більшого простору.

Конфігурація RAID для Firebird

Перш за все, слід переконатися, що в RAID є належно заряджений резервний акумулятор (BBU). Якщо такого акумулятора немає, більшість RAID перемикаються в безпечний режим запису (кеш диска повністю вимкнено), що забезпечує нижчу швидкість введення/виведення, ніж звичайний диск SATA!

Цей факт викликає більшість розчарованих повідомлень у технічну підтримку від користувачів, які придбали дорогий сервер і виявили, що він працює повільніше, ніж настільний комп’ютер. На жаль, деякі виробники не включають акумулятори за замовчуванням, тому це перше, що слід перевірити та виправити, якщо необхідно.

Потім слід налаштувати кеш читання та запису. Часто кеш вимкнено за замовчуванням, і якщо ви хочете зробити RAID досить швидким, вам потрібно увімкнути кеш.

Окрім увімкнення кешу, слід перевірити, як він працює - він може бути наскрізним (write through) і зворотним (write back). Швидкий спосіб роботи з кешем - write back: у цьому випадку будь-які зміни записуються в контролер кешу, а через деякий час безпосередньо на диск.

Ви можете використовувати інструменти виробників, що постачаються з RAID, щоб перевірити акумулятор, кеш і режим.

Сучасні RAID-контролери також можуть тонко налаштовувати кеш - його можна налаштувати для полегшення читання або запису. Зазвичай він розділений 50%/50% для читання та запису.

Щоб дізнатися, як саме налаштувати кеш, ви також можете використовувати інструмент MON$ Logger із розширеного пакета розповсюдження HQbird. Він показує співвідношення операцій читання та запису одна до одної (агреговане з моменту першого підключення до сервера):

Рисунок 8. HQbird MON$Logger: співвідношення читання/запису

Як ви можете бачити, у цьому прикладі операцій читання набагато більше, ніж операцій запису, тому має сенс налаштувати RAID-контролер на 80% операцій читання та 20% операцій запису.

SAN і бази даних

Інтегровані сховища стали популярними останнім часом. Вони включають гнучко налаштовуваний масив дисків (усі типи RAID) із розширеними функціями кешування. Зазвичай SAN мають кілька контролерів введення/виведення, що дозволяє обслуговувати кілька серверів одночасно та працювати досить швидко.

Багато організацій купують SAN і використовують їх у роботі з базами даних Firebird. Якщо SAN налаштовано правильно, можна досягти хорошої продуктивності. Слід враховувати такі питання, якщо ви використовуєте SAN:

Має бути доступно кілька високопродуктивних дискових контролерів, що забезпечують багатоканальний обмін даними.
Резервні акумулятори (BBU) мають бути присутні, якщо вони передбачені конструкцією.
Диски бази даних мають бути об’єднані в RAID10.
Кеш має бути увімкнено, режим запису має бути перемкнено на write back.
Якщо до SAN підключено кілька комп’ютерів, кожен із них повинен мати власний контролер.
Встановлено останні драйвери SAN. Ми стикалися з випадками, коли пізніші драйвери давали 30% приріст продуктивності.
Якщо на SAN є кілька логічних дисків (для баз даних, резервних копій, операційної системи), вони мають різні канали введення/виведення. Спроба використати один канал для всіх дисків разом призведе до зниження продуктивності.
Аналогічно, якщо кілька серверів і баз даних використовують SAN одночасно, продуктивність може бути нижчою через збільшену пропускну здатність контролерів введення/виведення.
Часто використовуються комбіновані способи - коли операційна система та тимчасові файли зберігаються на локальних дисках, а база даних і файли резервних копій - на SAN.

Часто SAN використовуються як “два сервери - один SAN” для створення відмовостійкого кластера. Слід зазначити, що такий кластер може вирішити проблеми, пов’язані лише з апаратними збоями на одному з серверів, шляхом негайного перемикання на другий сервер. Якщо проблема пов’язана з SAN або самою базою даних, це рішення не допоможе.

Щоб побудувати справді відмовостійке рішення, слід використовувати рішення, що реплікують дані між двома екземплярами бази даних. Ви можете зв’язатися з [email protected], щоб дізнатися більше про доступні рішення для Firebird.

Короткі висновки та рекомендації

Підсумуємо висновки та рекомендації щодо апаратного забезпечення для Firebird.

Багатоядерні процесори мають використовуватися для обслуговування великої кількості користувачів.
Мінімальний обсяг оперативної пам’яті розраховується на основі кількості користувачів і конфігурації бази даних; надлишковий обсяг оперативної пам’яті буде ефективно використано операційною системою для кешування файлу бази даних.
Використовуйте окремі диски для баз даних, тимчасових файлів і файлів резервних копій.
Краще використовувати SSD для баз даних.
Зарезервуйте щонайменше 30% вільного простору на SSD.
Бажано виділити окремий диск для бази даних.
Використовуйте корпоративні SSD (з великою кількістю циклів запису/читання).
Переконайтеся, що ви використовуєте RAID.
Для SSD - RAID1, для HDD - RAID10, для резервних HDD - RAID1. i. SAS, SATA, nSAS
Переконайтеся, що акумулятор RAID присутній і заряджений.
Переконайтеся, що він перемкнений у режим write back.
Деякі RAID-контролери мають уже налаштований розмір кешу, наприклад, 75% для читання, 25% для запису, або 50/50 тощо. Тому необхідно встановити MON$Logger - програмне забезпечення, яке контролюватиме параметри RAID, шукатиме співвідношення читання/запису та змінюватиме налаштування RAID.
Використання SAN має свої плюси та мінуси. Щоб отримати максимальну користь, слід правильно налаштувати SAN.
Щоб побудувати відмовостійке рішення, потрібно використовувати рішення з репліками, що працюють на різних серверах.

Контакти

Компанія IBSurgeon/IBase.ru розробляє розширений пакет розповсюдження HQbird для підприємств, надає комплексну технічну підтримку для Firebird і розробляє індивідуальні пакети розповсюдження, а також вирішує інші складні питання.

IBSurgeon також пропонує послугу оптимізації Firebird для покращення продуктивності бази даних Firebird.

Зв’яжіться з нами: [email protected]