Сегодня предлагаем вашему вниманию вторую часть статьи Светы Смирновой и Анастасии Распопиной о повышении производительности InnoDB.
Очень подробно этот вопрос также разберет Петр Зайцев, основатель компании Percona на своем мастер-классе 5 июля. Петр расскажет о том, как правильно использовать возможности MySQL 5.7 для того, чтобы обеспечить максимальную производительность, а также даст конкретные рекомендации относительно конфигурации сервера, схемы базы данных, архитектуры приложения и выбора оборудования. Не упустите возможность посетить этот уникальный мастер-класс, специально для PG Day Петр впервые в России подготовит его на русском языке!
В этой статье я расскажу, как искала узкое место, которое препятствовало повышению производительности в моём предыдущем посте.
Мощная машина, которую я использовала в тестах в своей предыдущей статье, имеет относительно медленный диск, и поэтому я ожидала, что мои тесты достигнут такого уровня, когда я не смогу больше увеличивать производительность из-за скорости диска.
Конфигурация аппаратных средств:
Процессоры: физические = 4, ядра = 72, виртуальные = 144, hyperthreading = да
Память: 3.0 TB
Скорость диска: около 3K IOPS
ОС: CentOS 7.1.1503
Файловая система: XFS
Протестированные версии и конфигурация: такие же, как в первой статье этой серии (почитайте её, чтобы узнать детали).
Хоть я и ожидала, что мои тесты перестанут расти в производительности из-за скорости диска, высоких значений IO в результатах iostat замечено не было. Я проводила тестирование с полным набором данных, помещающихся в память. В этом случае производительность записи влияла только на сброс данных на диск и запись в журнал. Но мы все равно должны увидеть заметное снижение скорости. Поэтому я решила попробовать RW-тесты полностью в памяти. Я создала ramdisk и установила на нем MySQL datadir. Удивительно, но результаты на SSD и ramdisk не отличались.
Я попросила своих коллег из Postgres Professional протестировать PostgreSQL с помощью ramdisk. Они получили похожие результаты:
Интересно, что значение innodb_io_capacity никак не влияет на эту ситуацию. Данные для графика ниже были взяты, когда я запускала тесты на ramdisk. Я хотела посмотреть, могу ли я, используя эту переменную, контролировать активность IO на диске, который по умолчанию очень быстр.
Это полностью противоречит всему моему прошлому опыту с менее производительными машинами. Percona переназначила машину с более быстрым диском (которую я использовала ранее в этой статье), поэтому я использовала аналогичную с меньшей скоростью диска.
Конфигурация аппаратных средств:
Процессоры: физические = 2, ядра = 12, виртуальные = 24, hyperthreading = да
Память: 47.2 GB
Скорость диска: около 3K IOPS
ОС: Ubuntu 14.04.5 LTS (trusty)
Файловая система: ext4
Опять же, в этом случае тесты innodb_io_capacity с меньшим количеством ядер процессора показали более предсказуемые результаты.
Заключение:
Как MySQL, так и PostgreSQL на машине с большим количеством процессорных ядер достигают пределов ресурсов CPU прежде, чем скорость диска может начать влиять на производительность. Однако мы протестировали только один сценарий. В других случаях результаты могут отличаться.
Свои вопросы Светлане вы можете оставить в комментариях, а также задать лично на ее мастер-классе в рамках PG Day'17 об отладке производительности MySQL.
Очень подробно этот вопрос также разберет Петр Зайцев, основатель компании Percona на своем мастер-классе 5 июля. Петр расскажет о том, как правильно использовать возможности MySQL 5.7 для того, чтобы обеспечить максимальную производительность, а также даст конкретные рекомендации относительно конфигурации сервера, схемы базы данных, архитектуры приложения и выбора оборудования. Не упустите возможность посетить этот уникальный мастер-класс, специально для PG Day Петр впервые в России подготовит его на русском языке!
В этой статье я расскажу, как искала узкое место, которое препятствовало повышению производительности в моём предыдущем посте.
Мощная машина, которую я использовала в тестах в своей предыдущей статье, имеет относительно медленный диск, и поэтому я ожидала, что мои тесты достигнут такого уровня, когда я не смогу больше увеличивать производительность из-за скорости диска.
Конфигурация аппаратных средств:
Процессоры: физические = 4, ядра = 72, виртуальные = 144, hyperthreading = да
Память: 3.0 TB
Скорость диска: около 3K IOPS
ОС: CentOS 7.1.1503
Файловая система: XFS
Протестированные версии и конфигурация: такие же, как в первой статье этой серии (почитайте её, чтобы узнать детали).
Хоть я и ожидала, что мои тесты перестанут расти в производительности из-за скорости диска, высоких значений IO в результатах iostat замечено не было. Я проводила тестирование с полным набором данных, помещающихся в память. В этом случае производительность записи влияла только на сброс данных на диск и запись в журнал. Но мы все равно должны увидеть заметное снижение скорости. Поэтому я решила попробовать RW-тесты полностью в памяти. Я создала ramdisk и установила на нем MySQL datadir. Удивительно, но результаты на SSD и ramdisk не отличались.
Я попросила своих коллег из Postgres Professional протестировать PostgreSQL с помощью ramdisk. Они получили похожие результаты:
Интересно, что значение innodb_io_capacity никак не влияет на эту ситуацию. Данные для графика ниже были взяты, когда я запускала тесты на ramdisk. Я хотела посмотреть, могу ли я, используя эту переменную, контролировать активность IO на диске, который по умолчанию очень быстр.
Это полностью противоречит всему моему прошлому опыту с менее производительными машинами. Percona переназначила машину с более быстрым диском (которую я использовала ранее в этой статье), поэтому я использовала аналогичную с меньшей скоростью диска.
Конфигурация аппаратных средств:
Процессоры: физические = 2, ядра = 12, виртуальные = 24, hyperthreading = да
Память: 47.2 GB
Скорость диска: около 3K IOPS
ОС: Ubuntu 14.04.5 LTS (trusty)
Файловая система: ext4
Опять же, в этом случае тесты innodb_io_capacity с меньшим количеством ядер процессора показали более предсказуемые результаты.
Заключение:
Как MySQL, так и PostgreSQL на машине с большим количеством процессорных ядер достигают пределов ресурсов CPU прежде, чем скорость диска может начать влиять на производительность. Однако мы протестировали только один сценарий. В других случаях результаты могут отличаться.
Свои вопросы Светлане вы можете оставить в комментариях, а также задать лично на ее мастер-классе в рамках PG Day'17 об отладке производительности MySQL.