Мы наняли консультанта, который помог нам увеличить емкость нашего кластера MySQL, и первое (почти единственное), что он сделал, - это измерил скорость дискового ввода-вывода наших серверов.
Меня интересует сравнение дискового ввода-вывода на аналогичных системах с тем, что есть у нас:
Выполнение следующих команд в поле MySQL дало мне такие результаты (которые консультант описал как «Ужасно медленные»:
time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 71.3347 seconds, 14.7 MB/s
real 1m13.596s
user 0m0.052s
sys 0m56.932s
time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 21.8202 seconds, 48.1 MB/s
real 0m21.902s
user 0m0.012s
sys 0m7.948s
Действительно ли эти результаты «ужасно медленные»?
Мне было бы интересно сравнить результаты, которые получают другие люди от этих двух команд на своих выделенных ящиках MySQL, особенно если это 32-разрядная виртуальная машина.
Следует знать, что ваша команда dd не будет обходить кеш файловой системы ОС. Это означает, что вы получите разные результаты в зависимости от того, что еще происходит, и вы заметите значительное изменение производительности по мере увеличения размера вывода (и, таким образом, исчерпания вашего кэша fs)
Добавьте "oflag = direct", чтобы обойти кеш файловой системы в выходном файле, например
time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 oflag=direct
Вы можете обойти кеш файловой системы для чтения, используя iflag = direct
Кроме того, ваша производительность будет сильно зависеть от размера блока. Хотя 1М является довольно хорошим компромиссом для тестирования последовательной записи, если ваше приложение не записывает 1М блоков, оно не будет репрезентативным для вашей реальной производительности.
В целом, эти показатели пропускной способности довольно ужасны - один диск sata (например, диски Seagate ES.2) может достигать максимальной скорости последовательной записи 105 МБ / с в начале диска и поддерживать ~ 60 МБ / с в течение весь диск.
Наконец, общие «передовые практики» баз данных говорят о том, что следует избегать RAID5 / 6 в качестве базовой системы для базы данных из-за относительно высоких накладных расходов, вызванных записью четности (не само вычисление четности, которое довольно дешево с точки зрения аппаратного обеспечения, а эффект о необходимости делать дополнительные чтения и записи при записи новой четности).
в большинстве случаев вам также следует сравнивать случайный io [например, с Бонни ++ ] не только линейное чтение / запись. или, может быть, это один большой приемник данных, который принимает журналы и сохраняет в неиндексированной огромной таблице?
результаты для dd 'benchmark'
szcapp1:/mnt/big/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 4.26186 s, 246 MB/s
real 0m4.563s
user 0m0.001s
sys 0m2.255s
szcapp1:/mnt/big/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.457162 s, 2.3 GB/s
real 0m0.459s
user 0m0.000s
sys 0m0.459s
szcapp1:/mnt/big/tmp#
64-битный Linux на dell poweredge 2950, perc6 raid 10 на 5x настольных дисках sata емкостью 500 ГБ. ОЗУ 16 ГБ, 2 четырехъядерных процессора с частотой 2,66 ГГц. но эй! в этом нет смысла - эти данные умещаются на 1/4 кеш-памяти рейд-контроллера, а остальные - в системной памяти.
ваши результаты действительно медленные. результаты работы виртуальной машины на Linux выше [32-разрядная гость Linux под vmware server 2.0]:
vfeed0:/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 15.996 s, 65.6 MB/s
real 0m16.043s
user 0m0.016s
sys 0m13.117s
vfeed0:/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.49413 s, 2.1 GB/s
real 0m0.505s
user 0m0.000s
sys 0m0.500s
vfeed0:/tmp#
имейте в виду, что производительность чтения фальшивая - она читается из кеша - если не из кеша гостя, то угрюмо из кеша хоста vmware.
Вот результаты моего сервера mysql. Это 64-битная, а не виртуальная машина, поэтому не уверен, насколько она полезна на самом деле, но есть очень значительная разница.
time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 5.72139 s, 183 MB/s
0.00s user 1.55s system 27% cpu 5.725 total
time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.432328 s, 2.4 GB/s
0.00s user 0.45s system 103% cpu 0.436 total
В дополнение к тому, что Дэниел Лоусон отметил о кэшированных результатах в ГБ / с ..
Если ваш dd не бывает поддержки iflag/oflag тогда вы можете вручную очистить кеш диска между запусками с помощью команды:
sync; echo 3 > /proc/sys/vm/drop_caches
Или просто используйте набор данных, который вдвое больше, чем ваша оперативная память, гарантирует, что данные никогда не будут кэшироваться между запусками.
Что касается вашего консультанта dd test - это хорошая отправная точка, но не окончательный. Он измеряет последовательный ввод / вывод. Это блоки чтения и записи, которые находятся непосредственно рядом друг с другом на физическом диске. К сожалению, базы данных очень редко имеют дело с последовательным вводом-выводом. Записи записываются в разное время и обычно не извлекаются с течением времени в том порядке, в котором они были написаны.
Имея это в виду, два важнейших фактора, которые необходимо измерить, - это пропускная способность случайного ввода-вывода и задержка. Они будут иметь наибольшее влияние на поведение MySQL. Для их измерения я предлагаю использовать утилиту bonnie++. В нем есть предустановленные тесты для тестирования всего вышеперечисленного, и его гораздо проще настраивать, если вы хотите протестировать определенные аспекты.
Вы также можете использовать MySQL супер-привкус для измерения повторяющейся производительности отдельных SQL-запросов.
Несколько в стороне от вашего первоначального вопроса; но ответ поставщика SAN на «RAID 5 работает медленно» заключается в преобразовании в RAID 1 или RAID 10. Также рассмотрите возможность выравнивания VMFS (PDF) может серьезно повлиять на производительность.
Когда мой дерьмовый старый Dell Latitude D520 (80Go; 5400RPM) бросает вызов вашему серверу MySQL, вы знаете, что где-то есть проблема ^^:
$ time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 32.5178 s, 32.2 MB/s
real 0m32.662s
user 0m0.008s
sys 0m2.716s
$ time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 29.8311 s, 35.2 MB/s
real 0m29.892s
user 0m0.004s
sys 0m2.056s
Сначала вам следует взглянуть на нагрузку, которую эти два теста оказывают на нагрузку ввода-вывода узлов ESX.
Затем выполните тест bonnie ++ в сочетании с iostat и mpstat, работающими в параллельных оболочках (ахой экран!) На этих узлах и в SAN, чтобы определить, где находится узкое место. Вы наверняка найдете где-нибудь большое количество айовейтов, на которых стоит сосредоточиться.