За последние пару недель в блоге было несколько сообщений о тестах, сравнивающих производительность различных версий MySQL и таких вариантов, как MariaDB. Также был проведен некоторый анализ результатов с использованием формальных моделей, таких как универсальный закон масштабируемости Нила Гюнтера .
Чему может научить нас Универсальный закон о масштабируемости (USL) о характеристиках производительности этих систем, выявленных в тестах? Чтобы выяснить это, я рассмотрю один конкретный тест производительности MariaDB 10.1 и MySQL 5.7 на обычном оборудовании .
Одним словом, контекст для этого теста заключается в том, что MySQL 5.7 был выпущен как GA, и опубликованные результаты производительности впечатляют с точки зрения пропускной способности на больших серверах. Хотя это хорошо, показывая, что MySQL может масштабироваться для выполнения большой работы на больших серверах, тестеры MariaDB хотели понять, как будет работать простой тест на типичном обычном сервере.
Тест сравнивает несколько версий MySQL. Нил написал в Твиттере анализ эталона с USL:
Будьте осторожны с этой диаграммой, потому что горизонтальная ось масштабирована, а не линейна. Что мы можем извлечь из этого? Прежде всего, если вы вообще знакомы с USL, вы сразу же поймете, что система ведет себя не так, как предсказывает USL. Гораздо лучший способ смоделировать это — использовать только первые несколько точек данных, чтобы предсказать, что может произойти, если система не столкнется с ограничением, которое мы видим, начиная с 8 соединений. Нил тоже сделал это :
Комментарий Нила, который я перефразирую для ясности, гласит : если вы можете устранить узкое место со скоростью 118 тыс. Запросов в секунду, USL предсказывает, что система достигнет потолка около 250 тыс. Запросов в секунду. Могут ли MySQL или MariaDB попасть туда? Если нет, то почему нет? С USL больше не в порядке просто измерять, вы должны ОБЪЯСНИТЬ данные.
Объяснение простое. Сервер имеет 4 ядра и 8 потоков:
Intel Xeon E5 E5–1630v3 4 / 8т
3,7 / 3,8 ГГц 64 ГБ ОЗУ
DDR4 ECC 2133 МГц 2 × 2 ТБ СОФТ
Этот сервер может выполнять только 8 запросов одновременно. После этого добавление новых соединений при попытке выполнения запросов не улучшит ситуацию.
USL не включает в себя параметры, которые моделируют фиксированный размер базового оборудования и других ресурсов, и в результате очень часто можно найти некоторый тип насыщения ресурсов, который создает потолок, который он не прогнозирует. Это прекрасный пример.
Как я обсуждаю в своей новой 50-страничной книге по Закону о универсальной масштабируемости , довольно бессмысленно пытаться использовать USL для оценки поведения за пределами точки насыщения, такой как та, которую вы видите в этом тесте. Вот почему адаптация USL к данным до 8 включений является правильным подходом.
За пределами точки насыщения все, что вы можете видеть, это то, работает ли сервер при увеличенной длине очереди эффективно или бесполезно. Большинство серверов теряют эффективность. Чтобы узнать, что именно является причиной этого, пожалуйста, прочитайте книгу, которую я связал выше.
Приведенные выше диаграммы представляют собой несколько версий сервера, проанализированных вместе. Я думаю, что лучше проанализировать только одну версию сервера. Давайте посмотрим на результаты для MySQL 5.6.27 только потому, что в этом тесте он побил другие версии:
clients qps
1 24456
2 45314
4 78024
8 126892
16 129029
32 127780
64 125526
128 124158
256 116337И анализ USL этих данных до 8 клиентов:
Коэффициент каппа настолько мал, что его следует игнорировать, однако сигма составляет около 7,4%, что весьма существенно и серьезно ограничивает производительность. Если вы знакомы с USL, это дает конкретные идеи о том, что необходимо изменить, и определяет, насколько вы можете масштабировать этот сервер в конфигурации такого типа. Когда я был в Percona в период с 2009 по 2011 годы, мы ставили перед собой задачу найти и устранить такие узкие места, что привело к появлению XtraDB и, в конечном итоге, к Percona Server.
Takeaways
- Когда система достигает очевидного предела, не пытайтесь приспособить USL к данным после этой точки, особенно когда вы знаете, что аппаратное обеспечение объясняет поведение просто.
- То, что происходит за пределами этой точки, указывает на способность сервера выходить за пределы насыщения, не выплескивая зерно. Мы видим, по сути, плоскую линию, но в более старых версиях MySQL мы видели серьезную ретроградную масштабируемость.
- Параметры USL указывают вам правильное направление для поиска и устранения проблем масштабируемости.
- Есть много странных и противоречивых результатов для множества тестов. Бенчмаркетинг есть везде. Узнайте о Универсальном законе масштабируемости и привейте себя против множества извращений мозга.