Eu tenho cerca de 16 sites em um CentOS dedicado, e estou tendo alguns problemas em altas horas de tráfego, parece ser uma alta atividade de E / S de disco causando uma lentidão geral.
Eu instalei no topo e é isso que eu vejo na parte inferior (o servidor foi reiniciado, por isso, os valores são tão baixos):
*** system and process activity since boot ***
PID RDDSK WRDSK WCANCL DSK CMD 1/18
2176 1.7G 7.3G 854.4M 39 mysqld
671 1248K 3.0G 0K 13 flush-8:0
566 0K 1.1G 0K 5 jbd2/sda2-8
2401 124.2M 529.1M 22408K 3 crond
2032 2.2G 502.0M 0K 12 nginx
2360 425.8M 115.3M 4188K 2 httpd
flush-8: 0 e jbd2 / sda2-8 são os processos que vejo com iotop usando 99% no IO > coluna, e eles são os processos que mais escrevem no disco rígido (depois do mysql). Pelo que eu vi no google isso pode ser causado por algum bug relacionado ao ext4, o kernel atual é:
Linux srvr.com 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 19:49:27 BST 2011 x86_64 x86_64 x86_64 GNU/Linux
Eu pedi ao suporte de hospedagem para atualizar o kernel e eles tentaram, mas agora dizem que o servidor não inicializará com o novo kernel instalado e eles tiveram que voltar ao anterior, eles não estão ajudando muito.
Alguém tem alguma idéia de como eu poderia resolver o alto uso de disco causado pelos processos flush-8: 0 e jbd2 / sda2-8?
Você não nos deu informações suficientes para eu contar, mas meu primeiro palpite é que você está usando demais a RAM e trocando de swap. no topo, mostre-nos a lista de memórias (pressione m), incluindo a seção do cabeçalho.
Não culpe seu apoio. Seu kernel e ext4 são muito improváveis de ser o problema.
flush-8:0 é thread do kernel, funciona na limpeza do buffer dirty RAM e / ou swap no disco, jbd2/sda2-8 é thread do kernel, que está trabalhando com registro no diário em sistemas de arquivos - são IO intensivos resultados , e não motivos do seu problema.
mais parece que seu problema é o uso pesado de disco pelo mysql. enquanto o JBD está em uso - parece que várias operações de gravação estão em andamento.
verifique quais arquivos são alterados pelo mysql ou verifique seus logs, uso do banco de dados, otimizações de tabela e se os daemons do mysql estão configurados para usar o máximo de RAM possível para o armazenamento em cache.
você pode usar o mysqltuner para recomendações genéricas.
se as gravações continuarem, provavelmente você precisará aumentar a velocidade do disco para mais IOPS.
verifique quais arquivos são mais frequentemente escritos. não apenas a taxa de MB / s é importante, você pode escrever 20 MB, mas consumir mais operações IO do que outras em 200 MB.
Aparentemente, o mysql não gosta de ext4. Atualizar o kernel ou mudar o diretório de dados mysql para a partição ext3 deve resolver este problema. link