Измеряем производительность «облачных» дисков — спасаем MySQL

от автора

В последнее время в облачных средах и хостингах все чаще стали попадаться «виртуальные» жесткие диски. Техническая служба хостера может заверять, что «виртуальный» диск — быстрый, как десяток рейдов 10 (рейд 100 😉 ) и держит сотни, а то и тысячи IOPS – однако MySQL заметно для клиентов тормозит. А как это доказать?

Проблема в том, что измерить «скорость» виртуального жесткого диска изнутри виртуальной машины – непросто, т.к. неясно, что мерить в первую очередь, чем и зачем 😉 А сделать это нужно, чтобы убедить администраторов виртуальной конфигурации, что дело не в приложении и настройках MySQL. И нужно было, как говориться, просто «помыть руки» перед чтением мануала к хранилищу.

В статье я проиллюстрирую простую методику нахождения «точки опрокидывания» производительности виртуального жесткого диска, с использованием доступных в дистрибутивах инструментов – sysbench и iostat. Также мы измерим «точку опрокидывания» известных своей тормознутостью виртуальных дисков EBS от Амазона – как обычных EBS, так и Provisioned IOPS EBS (1000 и 2000 IOPS).

Теория

К черту! Слишком много измерений и букв – последовательное чтение/запись, произвольное чтение/запись, перезаписи, влияние файлового кэша ядра, оптимизация очереди запросов, варианты опций и архитектуры файловой системы… Мы поступим проще – сэмулируем многопоточную нагрузку на виртуальный диск, подобную создаваемой сервером MySQL и посмотрим, как диску, или что за ним в сети скрывается, дышится.

А чтобы не было скучно, добавим к gnu.org немного романтики 🙂

Как MySQL нагружает диск

Для InnoDB, для типичного веб-приложения, если набор данных не помещается в оперативную память (именно поэтому были изобретены базы данных 😉 ), информация будет, в основном, считываться с диска в произвольном порядке (страницы buffer pool и кластеризованные индексы, хранящиеся на диске), а записываться — последовательно (журналы транзакций и бинарный лог).

Периодически buffer pool из оперативной памяти будет сбрасываться на диск – произвольная запись. Сразу исключаем отсутствие кэша записи и «батарейки» в виртуальном хранилище – оно должно быть, иначе MySQL в режиме ACID (innodb-flush-log-at-trx-commit=1) просто умрет от сожаления.

Важно понять тут, что запросы клиентов MySQL выполняет в параллельных потоках – и диск будет нагружаться, соответственно, несколькими потоками одновременно.

Создаем нагрузку

Начнем с простого EBS-диска амазона. Нагружать виртуальный диск будем инструментом sysbench (в CentOS он доступен пакетах, собрать из исходников несложно):

yum install sysbench mkdir -p /mount/disk_ebs/mysql/test_folder cd /mount/disk_ebs/mysql/test_folder sysbench --test=fileio --file-total-size=16G prepare 

Важный момент – создаем суммарный объем тестовых файлов (16G), превышающий как минимум в 2 раза объем оперативной памяти виртуальной машины (не спрашивайте, почему в 2 раза ;-), чем больше — тем лучше). Это нужно для уменьшения влияния файлового кэша операционной системы – при повторном запуске тестовые файлы лучше, поэтому, перегенерить заново (либо создать несколько тестовых папок и переключаться между ними).

Теперь создаем нагрузку в N потоков, эмулируя ~N клиентов сервера СУБД, выполняющих запросы (да я знаю, что внутри СУБД есть несколько служебных потоков, но не будем пока усложнять). Допустим, ожидается, что с БД будут одновременно работать 10 апачей:

sysbench --num-threads=10 --test=fileio --file-test-mode=rndrw --max-time=180 --file-rw-ratio='2' --file-total-size=16G --max-requests=1000000 run 

Что измеряем?

Теперь самое интересное. Нам не интересно, какие результаты покажет sysbench – он нам только нагрузку создает. Мы лишь смотрим, как чувствует себя виртуальный диск под нагрузкой:

iostat –xm 10 Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util  xvdm              0.00     0.00  120.50    0.00     2.05     0.00    34.79    10.50   87.47   8.30 100.00 

Диск «завален» запросами большую часть процессорного времени, что видно по «%util = 100» — драйвер диска накапливает запросы в очередь и по мере готовности устройства «скармливает» их (некоторые путают этот показатель с пропускной способностью шины к диску, что, конечно, неверно). Тут ясно, если драйвер вынужден ждать почти все время, то диск – загружен под завязку.

Среднее время обработки одного запроса «svctm» — 8.3 ms. Многовато, но нормально для дисков Амазона. Тут нет ничего криминального – обычная физика.

Среднее время ожидания обработки одного запроса «await» — 87.47 ms и средняя длина очереди запросов в драйвере диска «avgqu-sz» – 10.5. Это много, ждать почти 100 ms для обработки одного запроса! Очевидно, как получается эта величина – грубо размер очереди (avgqu-sz) умножается на время обработки одного запроса (svctm).

Итак, мы видим, что всего 10 конкурентных запросов на произвольное чтение/запись (ключи —file-test-mode=rndrw и —file-rw-ratio=’2′) приводят замедлению работы с виртуальным жестким диском.

Да так, что приходится ждать один запрос почти 100 ms. А если веб-страница создает 200 запросов к диску – сколько времени она будет строиться? 20 секунд?

Интересно, а при каком числе потоков диск Амазона не начинает накапливать очередь и обслуживает запросы быстрее хотя бы 50 ms (лучше вообще меньше 20 ms — субъективно)? Видим, что при 5 потоках. Конечно, это слабый показатель, без софтварного рейда не обойтись …

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util  xvdm              0.00     0.00  127.50    0.00     2.05     0.00    32.88     5.10   39.78   7.84 100.00 

Видим, что размер очереди – 5.1 и время выполнения одного запроса – 39.78.

Тестируем «быстрые» виртуальные диски Амазона

Относительно недавно Амазон анонсировал «быстрые» диски с гарантированным числом IOPS (теория IOPS – обширна, как наша страна, погуглите, en.wikipedia.org/wiki/IOPS). Мы знаем, что простые смертные SATA-диски не держат более 100 IOPS (одновременное чтение и запись), а, к сожалению, также смертные 15k SAS-диски – не более ~200 IOPS. Также известно, что SSD-диски и SAN на других технологиях могут осилить сотни, и даже тысячи IOPS – понятно, что они значительно дороже.

Итак, посмотрим, на каком числе одновременных потоков «быстрые» виртуальные диски Амазона начинают тупить и собирать запросы в очередь. Сломаем козе левую ногу!

Диск EBS с 1000 IOPS

Один поток:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util  xvdk              0.00     0.00 1084.50    0.00    27.33     0.00    51.61     3.72    3.43   0.91  99.20 

Обратите внимание на маленькое время обработки запроса самим виртуальным диском – 0.91 ms. Видимо массив на SSD 😉 Размер очереди ~4, а среднее время одного запроса – 3.43 ms.

20 потоков:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util  xvdk              0.00     0.00 1059.50    0.00    26.37     0.00    50.98    55.39   51.97   0.94 100.00 

Видим, что при 20 потоках запрос придется ждать ~50 ms из-за образования очереди в 55 запросов.

Диск EBS с 2000 IOPS

20 потоков:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util  xvdl              0.00     0.00 1542.50    0.00    36.29     0.00    48.18    33.20   21.29   0.65 100.00 

50 потоков:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util  xvdl              0.00     0.00 1498.50    0.00    36.63     0.00    50.06    86.17   57.05   0.67 100.00 

Итоги измерений

Видим, что EBS-диск с 2000 IOPS показывает примерно такую же latency (~50ms) на 50 потоках, как диск с 1000 IOPS на 20 потоках и обычный EBS диск на 6-7 потоках (видимо у обычных EBS дисков IOPS находится в пределах 200-300).

Что еще случается

Виртуальные жесткие диски нередко дарят сюрпризы. Иногда их просто недонастроили, т.к. не успели дочитать man…

Недавно столкнулся с подобным кейсом, когда при создании многопоточной тестовой нагрузки на пустом MySQL сервере у «большого-дорогого-быстрого-сетевого» виртуального диска скакал показатель svctm от 0.5 до 1 ms в ночное время и от ~10 до 100 ms – в дневное (хотел померить в полнолуние, не дождался). MySQL разумеется – тормозил. Причина была в параллельно использующих сетевое хранилище и незнающих друг о друге проектах, а не настройках MySQL, который пытались сделать виноватым 😉

Резюме

Используя подручные инструменты, мы довольно быстро определили предел конкурентной многопоточной нагрузки, при котором виртуальный диск начинает накапливать очередь и обслуживать довольно типичные для MySQL запросы за 50 ms и более. Теперь можно предположить, сколько дисков собрать в рейд, чтобы обеспечить latency, допустим, в 10-20 ms при заданном числе клиентов. Понятно, что это приблизительные данные, но они, безусловно, помогут двинуться дальше, особенно если измерить производительность настоящего жесткого диска/рейда и прийти с этими сравнительными данными и бутылкой шампанского к облачному хостеру;-)

В заключение, поздравляю всех с прошедшим праздником, желаю быстрых виртуальных дисков, надежных серверов и точных измерений! Заходите к нам на Битрикс24. Удачи!

ссылка на оригинал статьи http://habrahabr.ru/company/bitrix/blog/162501/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *