Solucionando problemas de desempenho do MySQL

Question

Ambiente:

1 máquina física

• 8 GB de RAM
• alguma CPU Core2Duo mais antiga
• 1 disco rígido
• Windows Vista de 64 bits

1 Máquina virtual

• 16 GB de RAM
• 2 vCPUs
• Windows 7 de 64 bits

Ambas as máquinas executando o MySQL 5.5.28 (64 bits) com bancos de dados idênticos. Eu estou administrando o ambiente VMWare e outro usuário está administrando a parte do banco de dados. A máquina física deve ser substituída pela máquina virtual, portanto, todos os dados foram migrados. Problema aqui é: o desempenho na VM é horrível. O DB-admin executa uma grande consulta diretamente em ambas as máquinas e a física é 2-3 vezes mais rápida que a VM. Então tentamos algumas coisas com a VM: mais RAM, mais CPUs, eu também conectei um dispositivo RAW com 16kb de tamanho, sem nenhum esforço. Física sempre supera a VM.

Nosso ambiente VMWare consiste em 3 hosts com:

• Host - Dell PowerEdge R720, 2x E5-2640, 8x 8 GB de RAM, Broadcom BCM57711 HBAs de 10 GB
• Comutação - Dell Powerconnect 8024F
• Armazenamento - Dell Equallogic PS4100X iSCSI
• VMWare 5.1, Clustred, HA, não distribuído vSwitch

Encontramos alguns problemas de configuração e fiz várias coisas para tentar melhorar o desempenho:

• O firewall dentro da VM está desativado
• A verificação de vírus está desativada
• o IPV6 está desativado

Nos Hosts houve um problema de latência que eu li sobre a Dell em relação a ACK e LRO atrasados por TCP - é recomendado desativá-los, e isso aumentou o throughput dentro das VMs (fiz um teste rápido com o IOMeter ). O banco de dados MySQL é meio pesado (arquivo de 120GB), se eu copiá-lo dentro da VM de um volume para outro com o Windows Explorer eu recebo constante 130mb / s (unidade VM c: - Windows, unidade e: - dispositivo bruto). Se a consulta for executada, posso ver no Monitor de Recursos do Windows que o arquivo é lido com ~ 500kb / s. Qual poderia ser o problema aqui?

O DBA também me disse que ele tentou configurações de banco de dados diferentes no my.ini, tentei dividir o enorme arquivo db em arquivos menores, tudo sem nenhum esforço (pessoalmente eu não sou um especialista em MySQL, então tenho que acreditar nele).

Eu sei que o Windows 7 não é o melhor sistema operacional para ser executado como um servidor de banco de dados, mas isso deve ser um teste rápido por alguns dias, depois usaremos o 2008 R2. Vou tentar fazer alguns testes com ioping e / ou IOMeter (alguma recomendação para isso?). Agradecemos antecipadamente.

EDITAR

Monitorando o dispositivo bruto diretamente na SAN:

Ao fazer uma consulta ao DB: link

Ao fazer o Filecopy com o Windows Explorer: link

Carga da CPU da VM ao fazer o acima: link

    

Answer 1

Seu problema é o back-end de armazenamento.

A partir do seu gráfico, fica claro que a sua SAN não é capaz de altos valores de IOPS aleatórios (veja ambas as estimativas de média e média da profundidade da fila).

Para melhorar a situação, tente o seguinte:

1. aumenta o tamanho do buffer pool innodb, editando o arquivo my.cnf e adicionando (ou alterando) a linha innodb_buffer_pool_size = 8589934592
2. se for possível, execute um teste com um disco diretamente conectado (local ao servidor R720) e não via SAN

Answer 2

Parece que a pilha de armazenamento VMWare está causando problemas. Mesmo que você tenha movido o host para seu próprio hardware, lembre-se de que, no armazenamento VMWare compartilhado, toda a carga de trabalho que usa o mesmo armazenamento de dados usa os mesmos recursos de armazenamento. O VMware ficou melhor em passar o desempenho bruto do armazenamento até suas VMs, mas não é tão bom quanto um dispositivo simples seria.

Teste esta teoria desta maneira: crie um mapa de dispositivos brutos para (talvez um clone de) sua VM e execute novamente o teste. Se estiver muito mais próximo dos resultados do servidor físico, existe o seu problema. Edit: Se você não pode usar um dispositivo bruto do Windows 7, você teria que tentar usando um sistema operacional do servidor. Se isso resolver o problema antes de você chegar ao dispositivo bruto, você terá outra resposta: P

Na minha loja, ainda estamos rodando o VMWare 4, então temos que usar o RDM para todos os nossos bancos de dados. Você pode não ter que ir tão longe como você está em uma versão melhor do VMWare, mas talvez tente dedicar um datastore com suas próprias luns em diferentes portas de armazenamento para este banco de dados.