Как вы проводите нагрузочное тестирование и планирование емкости для баз данных?

34

Это канонический вопрос о планировании емкости баз данных.

Связанный:

Я ищу, чтобы создать канонический вопрос об инструментах и ​​методах планирования емкости для баз данных. Это должно быть каноническим вопросом.

Очевидно, что общий рабочий процесс:

  • Поместите свой сценарий в место
  • Добавить мониторинг
  • Добавить трафик
  • Оценить результаты
  • Исправить на основе результатов
  • Промыть, повторить, пока не будет достаточно

Пожалуйста, не стесняйтесь описывать различные инструменты и методы для различных веб-серверов, фреймворков и т. Д., А также лучшие практики.

gWaldo
источник
База данных почти никогда не является автономной системой. Это видно из основного контекста, часто больших серверов приложений перед ними. БД являются внутренними устройствами данных. Таким образом, при тестировании нагрузки, вы должны учитывать это.
Нильс

Ответы:

24

Планирование емкости дисков и оперативной памяти

Планирование дискового пространства и объема памяти для сервера базы данных является черным делом. Чем больше, тем лучше. Быстрее, тем лучше.

В качестве общих указаний я предлагаю следующее:

  • Вы хотите , больше дискового пространства , чем вы когда - либо нужно.
    Оцените, сколько дискового пространства вам потребуется в течение следующих 3-5 лет, а затем удвойте его.
  • Вам понадобится достаточно оперативной памяти для хранения индексов базы данных в памяти, обработки самого большого запроса, по крайней мере, два раза, и при этом останется достаточно места для исправного дискового кэша ОС.
    Размер индекса зависит от вашей базы данных, а все остальное сильно зависит от вашего набора данных и структуры запроса / базы данных. Я предложу «По крайней мере, в два раза больше вашей самой большой таблицы» в качестве предложения, но учтите, что это предложение разбивает на действительно большие операции с хранилищами данных, где самая большая таблица может составлять десятки или сотни гигабайт.

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


Сравнительный анализ рабочей нагрузки и планирование производительности

Предполагая, что вы еще не развернули ...

Многие системы баз данных поставляются с Benchmarking Tools. Например, PostgreSQL поставляется с pgBench .
Эти инструменты должны стать вашей первой остановкой в ​​тестировании производительности базы данных. Если возможно, вы должны запустить их на всех новых серверах баз данных, чтобы понять, «сколько работы» может выполнять сервер баз данных.

Вооружившись теперь исходным тестом, ABSOLUTELY MEANINGLESSдавайте рассмотрим более реалистичный подход к тестированию: загрузите схему базы данных и напишите программу, которая заполняет ее фиктивными данными, а затем выполните запросы вашего приложения к этим данным.
Это тестирует три важные вещи: 1. Сервер базы данных (аппаратное обеспечение) 2. Сервер базы данных (программное обеспечение) 3. Структура вашей базы данных и как она взаимодействует с (1) и (2) выше.

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

Результаты этих тестов являются идеальным представлением вашей базы данных. На всякий случай предположим, что вы достигнете только 50-70% этой производительности в вашей производственной среде (остальное - подушка, которая позволит вам справиться с неожиданным ростом, сбоями оборудования, изменениями рабочей нагрузки и т. Д.).


Слишком поздно! Это в производстве!

Как только ваши системы будут запущены в эксплуатацию, будет слишком поздно проводить «тестирование» - вы можете на короткое время включить ведение журнала / синхронизацию запросов и посмотреть, сколько времени потребуется для выполнения, и вы можете выполнить некоторые «стресс-тестовые» запросы для больших наборов данных во время отключения. ч. Вы также можете посмотреть на использование ЦП, ОЗУ и пропускной способностью диска системы, чтобы понять, насколько сильно она загружена.
К сожалению, все эти вещи помогут вам понять, что делает система, и смутное представление о том, насколько она близка к насыщению.
Это подводит нас к ...


Текущий мониторинг

Все тесты в мире не помогут вам, если ваша система вдруг увидит новые / другие модели использования.
К лучшему или худшему, развертывания баз данных не являются статичными: ваши разработчики будут что-то менять, ваш набор данных будет расти (они никогда не уменьшаются), и ваши пользователи каким-то образом будут создавать безумные комбинации событий, которые вы никогда не предсказывали при тестировании.

Чтобы правильно планировать емкость вашей базы данных, вам необходимо внедрить некоторый мониторинг производительности, чтобы предупредить вас, когда производительность базы данных больше не соответствует вашим ожиданиям. На этом этапе вы можете рассмотреть корректирующие действия (новое оборудование, схема БД или изменение запроса для оптимизации использования ресурсов и т. Д.).


Примечание. Это очень общее руководство по определению размера оборудования базы данных и выяснению степени злоупотребления им. Если вы все еще не знаете, как определить, соответствует ли конкретная система вашим потребностям, вам следует обратиться к эксперту по базе данных.
Существует также сайт Stack Exchange, специально посвященный управлению базами данных: dba.stackexchange.com . Ищите их в архиве вопросов или просматривайте теги, специфичные для вашей базы данных, для получения дополнительных рекомендаций по настройке производительности.

voretaq7
источник
1
Кроме того, в настоящее время вы можете использовать твердотельные накопители для операций подкачки / записи на диск. Это ускорит запросы, которые используют большие временные таблицы на дисках. Таким образом, добавление большего количества твердотельных накопителей, как правило, очень хорошая идея.
Питер
2
@ Питер Я бы не советовал использовать твердотельные накопители для пространства подкачки (если вы активно меняете местами, там очень высокая скорость оттока), хотя при достаточно большом SSD и хорошем выравнивании износа диск может продлить срок службы машины. Я видел SSD, используемые для временного табличного пространства с хорошими результатами.
voretaq7
1
Обратите внимание, что этому совету в комментариях о твердотельных накопителях уже 7 лет. Каждое хранилище, которое содержит базу данных на вашем сервере баз данных, должно быть SSD в 2019 или позже.
Марк Хендерсон
1

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

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

Затем создайте клиентскую часть. Часто одной физической машины недостаточно для создания производственной нагрузки.

Затем включите его, оцените, улучшите и проверьте снова.

Вы будете удивлены, где возникают узкие места.

Nils
источник