☰

Procurando comparações de E/S de disco para um servidor MySQL dedicado

tag-icon • tag-icon mysql performance performance-tuning
Procurando comparações de E/S de disco para um servidor MySQL dedicado

Contratamos um consultor para nos ajudar a aumentar a capacidade do nosso cluster MySQL, e a primeira coisa (quase única) que ele fez foi medir a velocidade de E/S do disco dos nossos servidores.

Estou interessado em uma comparação de E/S de disco em sistemas semelhantes ao que temos:

  • Nossos servidores MySQL são servidores virtuais rodando em VMWare ESX 3.5 de 32 bits com SCSI SAN (Raid 5), e os próprios servidores virtuais estão rodando Debian Etch e MySQL versão 5.0.32

A execução dos seguintes comandos na caixa MySQL fornece esses resultados para mim (que o consultor descreveu como "Terrivelmente lento":

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

Esses resultados são realmente “terrivelmente lentos”?

Eu estaria interessado em comparar os resultados que outras pessoas obtêm com esses dois comandos em suas caixas MySQL dedicadas - principalmente se for uma máquina virtual de 32 bits.

Responder1

Algo a ter em conta é que o seu comando dd não irá ignorar o cache do sistema de arquivos do sistema operacional. Isso significa que você obterá resultados variados dependendo do que mais está acontecendo e notará uma variação significativa de desempenho à medida que aumenta o tamanho da saída (e, assim, esgota o cache do fs)

Adicione o "oflag=direct" para ignorar o cache do sistema de arquivos no arquivo de saída, por exemplo

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

Você pode ignorar o cache do sistema de arquivos para leitura usando iflag=direct

Além disso, seu desempenho variará muito com o tamanho do bloco. Embora 1M seja uma boa compensação para testar gravações sequenciais, a menos que seu aplicativo esteja gravando blocos de 1M, isso não representará seu desempenho real.

Como ponto geral, esses números de rendimento são bastante péssimos - uma única unidade sata (como as unidades Seagate ES.2) pode atingir o pico de gravação sequencial de 105 MB/s no início da unidade e sustentará ~ 60 MB/s durante o unidade inteira.

Finalmente, as "melhores práticas" gerais de banco de dados dizem para evitar o RAID5/6 como um sistema subjacente para um banco de dados, devido à sobrecarga relativamente alta causada pelas gravações de paridade (não o cálculo de paridade em si, que é bastante barato em hardware, mas o efeito de ter que fazer leituras e gravações extras ao escrever uma nova paridade).

Responder2

Aqui estão os resultados do meu servidor mysql. É uma máquina de 64 bits, não virtual, então não tenho certeza de quanto ela realmente é útil, mas há uma diferença considerável.

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

Responder3

na maioria dos casos, você também deve comparar io aleatório [por exemplo, comBonnie++] não apenas leitura/gravação linear. ou talvez seja um coletor de big data que coleta logs e armazena em uma tabela enorme não indexada?

resultados para 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#

Linux de 64 bits no Dell Poweredge 2950, ​​Perc6 RAID 10 em 5 discos SATA de 500 GB para desktop. 16 GB de RAM, 2x quad core 2,66 GHz. mas ei! isso não faz sentido - esses dados cabem em 1/4 da memória cache do controlador RAID e o restante - na memória do sistema.

seus resultados são realmente lentos. resultados da VM em execução no Linux acima [convidado Linux de 32 bits no servidor VMware 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#

tenha em mente que o desempenho de leitura é falso - é lido no cache - se não no cache do convidado, então é grosseiro no cache do host VMware.

Responder4

Um pouco longe da sua pergunta original; mas a resposta do fornecedor SAN para "RAID 5 é lento" é converter para RAID 1 ou RAID 10. Considere também o alinhamento VMFS (PDF) pode estar afetando gravemente o desempenho.

informação relacionada