Alta espera de E / S - como determinar a causa raiz?

10

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?

Bob Sauvage
fonte
Talvez fora de tópico: mas por que RAID5 em um banco de dados? Má ideia devido à diferença de gravação. O HW com BBU atenua um pouco isso, mas o RAID 5 é basicamente bom para leitura, não para escrever pequenas transações.
Hennes
Porque eu não tinha escolha ... RAID 10 não foi apoiada neste controlador RAID (com minha versão do RHEL) ...
Bob Sauvage
@BobSauvage algum progresso?
Huygens
Só para esclarecer: o io-wait inclui também a espera nos descritores de arquivos não fornecidos pelo armazenamento em massa? como soquetes ...
Massimo

Respostas:

7

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.

Huygens
fonte
A postagem do blog Percona mencionada na resposta de ajuste para melhorar o desempenho do innodb foi atualizada com: Atualização: não faça isso, foi comprovado que dados corrompidos!
vkats
@vkats muito obrigado. Atualizei a resposta para remover a sugestão e o artigo.
Huygens
1

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.

ludvik02
fonte
meu jbd2 / dm-2-8 parece o tempo todo em torno de 8,5% no iotop, mas .. Eu não acho que seja problemático, pois não há leitura de disco, e a gravação total do disco é de 35 MB após 1 hora. btw, em / dev há no máximo dm-2 (que -8 eu não tenho idéia de onde é ..) #
50000 Aquarius Power