Portanto, temos um servidor que apresenta picos aparentemente aleatórios na E/S de disco, subindo até 99,x% em momentos aleatórios e sem motivo óbvio, permanecendo alto por um tempo e depois voltando a cair. Isso não costumava ser um problema, mas recentemente a E/S do disco tem permanecido em 99% por longos períodos de tempo, em alguns casos até 16 horas.
O servidor é um servidor dedicado, com 4 núcleos de CPU e 4 GB de RAM. Ele está executando o Ubuntu Server 14.04.2, executando o percona-server 5.6 e nada mais importante. Ele está sendo monitorado quanto ao tempo de inatividade e temos uma tela mostrando permanentemente CPU/RAM/E/S de disco para os servidores com os quais lidamos. O servidor também está sendo corrigido e mantido regularmente.
Este servidor é o terceiro em uma cadeia de réplicas e funciona como uma máquina de failover. O fluxo de dados do MySQL é o seguinte.
Mestre -> Mestre/Escravo -> Servidor Problema
Todas as três máquinas têm especificações idênticas e são hospedadas pela mesma empresa. O servidor com problema está em um datacenter diferente do primeiro e do segundo.
A ferramenta 'iotop' nos mostra que a E/S do disco está sendo causada pelo processo 'jbd2/sda7-8'. Pelo que sabemos, isso lida com o diário do sistema de arquivos e com a liberação de coisas para o disco. Nossa partição 'sda7' é '/var' e nossa partição sda8 é /home. Nada deve ser lido/escrito em/home regularmente. Parar o serviço mysql resulta na E/S do disco caindo imediatamente para um nível normal, então temos quase certeza de que é percona que está causando o problema, e isso corresponderia ao fato de ser a partição /var, pois é aqui que nosso MySQL o diretório de dados reside (/var/lib/mysql).
Usamos NewRelic para monitorar todos os nossos servidores e, quando a E/S do disco aumenta, não conseguimos ver nada que possa estar causando isso. A média de carga fica em ~2. O uso da CPU gira em torno de 25%, o que a NewRelic diz ser causado por ‘IO Wait’ e não por um processo específico.
Nosso arquivo de configuração mysql foi gerado através de uma combinação do assistente de configuração Percona e algumas configurações que são necessárias para o aplicativo de nossos clientes, mas não é nada particularmente sofisticado.
Configuração do MySQL -http://pastebin.com/5iev4eNa
Tentamos o seguinte para tentar resolver o problema:
Executei mysqltuner.pl para ver se havia algo obviamente errado. Os resultados são muito semelhantes aos resultados da mesma ferramenta nos outros 2 servidores de banco de dados e não mudam muito entre os usos.
Usei vmstat, iotop, iostat, pt-diskstats, fatrace, lsof, pt-stalk e provavelmente mais alguns, mas nada óbvio apareceu.
Ajustou a variável 'innodb_flush_log_at_trx_commit'. Tentei configurá-lo para 0, 1 e 2, mas nenhum pareceu surtir efeito. Isso deveria ter mudado a frequência com que o MySQL liberava transações para os arquivos de log.
Um 'show full processlist' do mysql é muito desinteressante quando a E/S do disco está alta, apenas mostra a leitura do escravo do mestre.
Algumas das saídas das ferramentas são obviamente muito longas, então darei links para pastebin e não consegui copiar e colar a saída do iotop, então forneci uma captura de tela.
iotop
pt-diskstats:http://pastebin.com/ZYdSkCsL
Quando a E/S do disco está alta, “vmstat 2” nos mostra que as coisas que estão sendo gravadas são principalmente por causa de “bo” (buffer out), que se correlaciona com o diário do disco (liberação de buffers/RAM para disco)
“lsof -p mysql-pid” (lista os arquivos abertos de um processo) nos mostra que os arquivos que estão sendo gravados são principalmente arquivos .MYI e .MYD no diretório /var/lib/mysql, e o master.info e o relay- bin e arquivos de log de retransmissão. Mesmo sem especificar o processo mysql (qualquer arquivo sendo gravado em todo o servidor), a saída é muito semelhante (principalmente arquivos MySQL, nada mais). Isso confirma para mim que definitivamente está sendo causado por Percona.
Quando a E/S do disco está alta, “seconds_behind_master” aumenta. Não tenho certeza de como eles acontecem ainda. “seconds_behind_master” também salta temporariamente de valores normais para valores arbitrariamente grandes e depois retorna ao normal imediatamente. Algumas pessoas sugeriram que isso pode ser causado por problemas de rede.
'mostrar status de escravo' -http://pastebin.com/Wj0tFina
O controlador RAID (3ware 8006) não possui nenhuma capacidade de cache; alguém também sugeriu que o baixo desempenho do cache poderia estar causando o problema. O controlador possui firmware, versão, revisão, etc. idênticos aos de placas em outros servidores para o mesmo cliente (embora servidores web), então tenho quase certeza de que não há culpa. Também executei verificações do array, que deram certo. Também temos o script de verificação RAID que nos alertaria sobre quaisquer alterações.
As velocidades da rede são terríveis em comparação com as do segundo servidor de banco de dados, então estou pensando que talvez seja um problema de rede. Isso também se correlaciona com picos na largura de banda pouco antes de a E/S do disco aumentar. No entanto, mesmo quando a rede “aumenta”, ela não atinge uma grande quantidade de tráfego, apenas relativamente alta em comparação com a média.
Velocidades de rede (geradas usando iPerf para uma instância AWS)
Servidor com problema - 0,0-11,3 seg 2,25 MBytes 1,67 Mbits/seg Segundo servidor - 0,0-10,0 seg 438 MBytes 366 Mbits/seg
Além de lenta, a rede parece estar bem. Sem perda de pacotes, mas com alguns saltos lentos entre servidores
Terei prazer em fornecer também a saída de quaisquer comandos relevantes, mas só posso adicionar 2 links a esta postagem porque sou um novo usuário :(
EDITAREntramos em contato com nosso provedor de hospedagem sobre esse problema e eles tiveram a gentileza de trocar os discos rígidos por SSDs do mesmo tamanho. Reconstruímos o RAID nesses SSDs, mas infelizmente o problema persiste.
Responder1
Qual versão do servidor MySQL você usa? Após a versão 5.5, você pode usar performance_schema para obter estatísticas em tempo real do banco de dados. Eu começaria a consultar o
table_io_waits_summary_by_table
table_io_waits_summary_by_table
table_lock_waits_summary_by_table
para ver o que está acontecendo exatamente.
Uma outra solução seria se você verificasse o uso do buffer pool, não é possível, se há páginas frias que precisam ser movidas para a memória?
Responder2
A melhor maneira de atacá-lo é olhar parahttp://www.brendangregg.com/linuxperf.htmle siga o conselho de Brendan.
Especificamente, você deseja a ferramenta iosnoop que lhe dirá quem acessa mais o armazenamento. Mas você fará um grande favor a si mesmo se ler para aprender seu processo de pensamento e metodologias, pois isso o beneficiaria muito a longo prazo.