Базы данных с открытым исходным кодом на больших машинах: скорость диска и innodb_io_capacity. Часть 2

Сегодня предлагаем вашему вниманию вторую часть ^[1] статьи Светы Смирновой ^[2] и Анастасии Распопиной о повышении производительности InnoDB.

Очень подробно этот вопрос также разберет Петр Зайцев ^[3], основатель компании Percona на своем мастер-классе 5 июля. Петр расскажет о том, как правильно использовать возможности MySQL 5.7 для того, чтобы обеспечить максимальную производительность, а также даст конкретные рекомендации относительно конфигурации сервера, схемы базы данных, архитектуры приложения и выбора оборудования. Не упустите возможность посетить этот уникальный мастер-класс ^[4], специально для PG Day Петр впервые в России подготовит его на русском языке!

В этой статье я расскажу, как искала узкое место, которое препятствовало повышению производительности в моём предыдущем посте ^[5].

Мощная машина, которую я использовала в тестах в своей предыдущей статье ^[5], имеет относительно медленный диск, и поэтому я ожидала, что мои тесты достигнут такого уровня, когда я не смогу больше увеличивать производительность из-за скорости диска.

Конфигурация аппаратных средств:
Процессоры: физические = 4, ядра = 72, виртуальные = 144, hyperthreading = да
Память: 3.0T
Скорость диска: около 3K IOPS
ОС: CentOS 7.1.1503
Файловая система: XFS

Протестированные версии и конфигурация: такие же, как в первой статье ^[5] этой серии (почитайте её, чтобы узнать детали).

Хоть я и ожидала, что мои тесты перестанут расти в производительности из-за скорости диска, высоких значений IO в результатах iostat замечено не было. Я уже проводила тестирование с полным набором данных, помещающихся в память. В этом случае производительность записи влияла только на сброс данных на диск и запись в журнал. Но мы все равно должны увидеть заметное снижение скорости. Поэтому я решила попробовать RW-тесты полностью в памяти. Я создала ramdisk ^[6] и установила на нем MySQL datadir. Удивительно, но результаты на SSD и ramdisk не отличались.

Я попросила моих коллег из Postgres Professional ^[7] протестировать PostgreSQL с помощью ramdisk. Они получили похожие результаты:

Интересно, что значение innodb_io_capacity никак не влияет на эту ситуацию. Данные для графика ниже были взяты, когда я запускала тесты на ramdisk. Я хотела посмотреть, могу ли я, используя эту переменную, контролировать активность IO на диске, который по умолчанию очень быстр.

Это полностью противоречит всему моему прошлому опыту с менее производительными машинами. Percona переназначила машину с более быстрым диском (которую я использовала ранее в этой статье ^[5]), поэтому я использовала аналогичную с меньшей скоростью диска.

Конфигурация аппаратных средств:
Процессоры: физические = 2, ядра = 12, виртуальные = 24, hyperthreading = да
Память: 47.2G
Скорость диска: около 3K IOPS
ОС: Ubuntu 14.04.5 LTS (trusty)
Файловая система: ext4

Опять же ^[5], в этом случае тесты innodb_io_capacity с меньшим количеством ядер процессора показали более предсказуемые результаты.

Заключение:

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

Свои вопросы Светлане вы можете оставить в комментариях, а также задать лично на ее мастер-классе ^[8] в рамках PG Day'17 об отладке производительности MySQL.

Автор: rdruzyagin

Источник ^[9]