Eu tenho uma instância do MySQL em dois servidores dedicados. Um para a produção, o outro para a plataforma de teste.

Os 2 servidores são praticamente os mesmos, a única diferença é o controlador RAID e o volume virtual (o HD é o mesmo). Na produção, há um controlador HW RAID dedicado e um volume RAID 10. Por outro lado, o controlador RAID parece ser um software (Lenovo ThinkServer RAID 110i) e o volume é RAID 5.

Percebemos que durante o commit do MySQL, temos um alto iowait:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8 e dm-14-8 estão relacionados a partições de banco de dados.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

Eu suspeito que o controlador de invasão, como posso ter certeza?

Minha resposta teve duas partes: investigação do driver do dispositivo de bloco; e otimização vale a pena analisar com seu caso de uso. Mas eu removi a última parte, pois foi relatado que isso pode levar à perda de dados. Ver comentários.

Investigação de Hardware

Entendi que para o mesmo aplicativo, mas em 2 conjuntos diferentes de hardware, o desempenho é muito diferente e você gostaria de entender o porquê. Portanto, proponho primeiro um meio para ajudá-lo a encontrar uma resposta para o "porquê".

Para desempenho, costumo me referir ao Mapa de Desempenho do Linux fornecido por Brendan Gregg em seu blog. Pode-se ver que para o nível baixo (próximo ao hardware) uma ferramenta como blktraceseria perfeito.

Não conhecendo realmente essa ferramenta, pesquisei e encontrei este artigo interessante sobre Marc Bloker, sobre blktrace . Basicamente, sugere o seguinte: executando um rastreamento de E / S usando blktrace; usando a ferramenta btt para extrair informações desse rastreamento. Isso seria algo assim (para um rastro de 30 s):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

A saída pode ser bastante longa, mas procure entradas D2C. Ele fornecerá uma idéia do tempo que leva para uma E / S entregue ao driver do dispositivo ser relatada como concluída por esse driver.

Exemplo de saída ( dnf upgradeexecutando em uma VM do VirtualBox no meu laptop ocupado):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

Ele mostra uma média decepcionante de 45 ms por E / S com até 3,94 s para o pior caso !!

Para mais maneiras de usar o blktrace para executar esta investigação, leia o artigo de Marc Brooker, muito instrutivo.

O processo jbd2 é para o diário ext4. É lógico que o sistema de arquivos precise gravar no diário durante as confirmações do mysql, isso não deve ser motivo de preocupação. A quantidade de carga causada pelo jbd é influenciada pelos parâmetros de montagem das partições dm-10-8 e dm-14-8. Provavelmente, é desejável ter um diário muito conservador na partição do banco de dados para garantir que o banco de dados não seja corrompido se algo acontecer e o servidor for reiniciado acidentalmente. Você pode selecionar outras opções de montagem de diário no ambiente de teste apenas para comparação.