Руководство по аппаратному обеспечению Firebird

_by 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). Как только этот предел превышен, в папке с временными файлами создается временный файл (с соответствующим флагом операционной системы), который используется для сортировки. Если в системе есть свободная оперативная память, файл сортировки будет кэшироваться операционной системой, и сортировка будет выполняться в памяти.
Глобальные временные таблицы (GTT) создаются как временные файлы в операционной системе. Если у операционной системы есть свободная память, операции с GTT выполняются в оперативной памяти.

Основные операции с оборудованием

Давайте посмотрим, как функциональные модули Firebird взаимодействуют с аппаратными компонентами во время операций, выполняемых в процессе работы с базами данных.

После запуска Firebird серверный процесс занимает минимальный объем оперативной памяти (несколько мегабайт) и не выполняет интенсивных операций с 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
Дисковый ввод/вывод	10	10	1	1	1	1	1	1

Как вы можете видеть, наиболее ресурсоемкими операциями являются те, которые связаны с доступом к диску, потому что диски остаются самым медленным аппаратным компонентом, несмотря на прогресс последних лет, связанный с SSD.

Это приводит к одному из способов оптимизации производительности, который полностью связан с оборудованием - перенести все операции чтения-записи в оперативную память. Но обратите внимание, что подход с увеличением кэша страниц не работает. Мы подробно рассмотрим этот вопрос в разделе об оперативной памяти.

Одновременно выполняемые операции

Обычно необходимо выбирать оборудование для сервера, который будет обслуживать множество клиентов, поэтому очень важно понимать, как реализован параллелизм операций.

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

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

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

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

Потоки данных

При выполнении SQL-запросов Firebird читает и записывает много данных, передает их между функциональными модулями и соответствующими аппаратными компонентами. Чтобы выявить возможные узкие места, нам нужно понять, как осуществляется обмен данными. Рисунок 2 ниже поможет нам в этом:

Рисунок 2. Потоки данных между оперативной памятью и постоянным хранилищем

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

Резервное копирование

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 ГБ памяти. Вы можете скачать их здесь: /ru/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) заметят нехватку места для резервных копий и отправят соответствующее сообщение администратору.

Жесткий диск для базы данных

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 - RAID 1, для 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]