☰

Ищу сравнения дискового ввода-вывода для выделенного сервера MySQL

tag-icon • tag-icon mysql performance performance-tuning
Ищу сравнения дискового ввода-вывода для выделенного сервера MySQL

Мы наняли консультанта, чтобы он помог нам увеличить емкость нашего кластера MySQL, и первое (почти единственное), что он сделал, — измерил скорость дискового ввода-вывода наших серверов.

Мне интересно сравнение дискового ввода-вывода на аналогичных системах с тем, что есть у нас:

  • Наши серверы MySQL — это виртуальные серверы, работающие на 32-битной VMWare ESX 3.5 с SCSI SAN (Raid 5), а сами виртуальные серверы работают под управлением Debian Etch и MySQL версии 5.0.32.

Выполнение следующих команд на сервере 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-битная виртуальная машина.

решение1

Что нужно знать, так это то, что ваша команда dd не будет обходить кэш файловой системы ОС. Это означает, что вы получите различные результаты в зависимости от того, что еще происходит, и вы заметите значительные изменения производительности по мере увеличения размера вывода (и, таким образом, исчерпывания вашего кэша fs)

Добавьте «oflag=direct», чтобы обойти кэш файловой системы в выходном файле, например:

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 oflag=direct

Вы можете обойти кэш файловой системы для чтения, используя iflag=direct

Кроме того, ваша производительность будет сильно меняться в зависимости от размера блока. Хотя 1M — это довольно хороший компромисс для тестирования последовательных записей, если ваше приложение не записывает блоки размером 1M, это не будет репрезентативным для вашей фактической производительности.

В целом эти показатели пропускной способности просто ужасны: один диск SATA (например, диск Seagate ES.2) может достигать пиковой скорости последовательной записи 105 МБ/с в начале диска и поддерживать ее на уровне около 60 МБ/с на всем диске.

Наконец, общие «рекомендации» по работе с базами данных говорят о необходимости избегать RAID5/6 в качестве базовой системы для базы данных из-за относительно высоких накладных расходов, вызванных записью четности (не самого фактического вычисления четности, которое довольно дешево с точки зрения оборудования, а эффекта необходимости выполнять дополнительные чтения и записи при записи новой четности).

решение2

Вот результаты моего сервера 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

решение3

в большинстве случаев вы также должны сравнивать случайные данные [например, сБонни++] не только линейное чтение/запись. или, может быть, это один большой приемник данных, который принимает логи и сохраняет их в огромной неиндексированной таблице?

результаты для 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 на 5 дисках SATA по 500 ГБ. 16 ГБ оперативной памяти, 2 четырехъядерных процессора по 2,66 ГГц. Но эй! Это же бессмыслица — эти данные умещаются на 1/4 кэш-памяти RAID-контроллера, а остальное — в системной памяти.

Ваши результаты действительно медленные. Результаты с виртуальной машины, работающей на 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.

решение4

Несколько отклоняюсь от вашего изначального вопроса; но ответ поставщика SAN на вопрос «RAID 5 медленный» — преобразовать в RAID 1 или RAID 10. Также рассмотрите выравнивание VMFS (PDF) может серьезно повлиять на производительность.

Связанный контент