Деградация производительности Firebird: тесты, мифы и правда
Alexey Kovyazin, 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, ОЗУ 16 ГБ, программный RAID1 SATA 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
Как вы можете видеть, производительность при случайных операциях ввода-вывода показывает примерно в 8 раз лучшие результаты для SSD-диска. Мы знали из нашего опыта с базами данных клиентов, что SSD на 30-50% быстрее в реальных приложениях, но увеличение в 8 раз очень высокое.
Однако этот тест искусственный и специально разработан для имитации высоконагруженных OLTP-операций с множеством обновлений/удалений, но без больших выборок. Обычное приложение базы данных не работает в таком режиме всё время. Это объясняет, почему SSD показывает такие высокие результаты в данном конкретном случае.
Резюме
Итак, что мы узнали из этих тестов?
Прежде всего - производительность Firebird не имеет больших падений, связанных с каким-либо ограничением размера. На одном и том же оборудовании производительность будет медленно снижаться с ростом размера базы данных. Такое снижение производительности можно компенсировать настройкой конфигурации Firebird или разумным обновлением оборудования.
Здесь уместно упомянуть, что IBSurgeon предлагает услугу оптимизации производительности Firebird - используя экспериментальные данные, собранные из таких тестов, мы можем значительно повысить производительность баз данных Firebird и InterBase.
Затем мы узнали, что даже очень большие базы данных Firebird (1.7 терабайта) будут работать на недорогом оборудовании со значительной, но приемлемой потерей производительности.
И в-третьих, SSD действительно хорош для OLTP-приложений. Вероятно, это самый дешёвый способ повысить производительность базы данных на данный момент. Конечно, использование SSD не исправит проблемы с плохими планами запросов и неэффективными индексами, но может повысить производительность в целом.
Продолжение следует: Подробнее о базе данных Firebird 1.7 Терабайт.