Estou administrando um grande servidor LAMP com alguns milhares de usuários. Cerca de uma semana atrás, as coisas desaceleraram e a única coisa que vejo é que a latência de IO é aumentada dramaticamente . Os usuários experimentam carregamentos de página lentos e eu tenho segundos de interrupção quando quero salvar um arquivo.
O sistema operacional é o CloudLinux, kernel 2.6.32. Além disso, uma maravilhosa combinação de CageFS e cPanel. O hardware é um IBM X3630 M3, com 11 unidades no hardware RAID 5 + uma unidade sobressalente.
Eu fiz muitos experimentos. Primeiro, corri iotop -oaP para ver o que está fazendo muita largura de banda de IO. Todos os processos que acabaram nas primeiras posições são serviços LAMP normais. Aqueles não pareciam fazer muito mais IO do que deveriam - embora eu não saiba o estresse ideal ou normal no servidor. Infelizmente, não consigo acessar as informações do sysstat dos dias em que a latência do IO era normal, apenas os gráficos do munin. Por outro lado, o CageFs deve limitar a atividade de todos os usuários.
Então, comecei a pensar que os discos recebiam muitas IOPS, que eles não suportavam. O utilitário proprietário megacli diz que não há mau funcionamento sobre a matriz RAID, nenhuma reconstrução está em andamento ou algo incomum. Executando sar por horas Eu experimentei IOPS acima de 5000, mas os problemas ainda estão lá quando o sistema está fazendo menos de 1K IOPS, então eu acho que os discos estão bem?
Eu tentei o framework de auditoria e o system tap, mas ambos falharam em ser úteis (o primeiro suspendeu todo o sistema e eu não consegui obter muitas estatísticas, o último nem sequer funcionou)
O que estou fazendo agora é comparar a velocidade do meu laptop minúsculo com o servidor com vários testes. Foi assim que descobri que, embora eu possa criar arquivos de 100K com o seguinte script no meu laptop (com um HDD pequeno e lento) em 3 a 5 segundos, o servidor faz isso em mais de 20 a 30 segundos.
#!/bin/bash
i=1
while (( $i < $1 )); do
echo $i
echo "foobartest" > tmp/iotest.$i
(( i++ ))
done
Isso pode ser devido ao servidor atendendo a 50-100 solicitações HTTP por segundo, mas o mais estranho é que, se eu observar os números em execução no terminal, às vezes ele fica travado por vários segundos, antes que possa criar o próximo arquivo.
A coisa que estou fazendo atualmente é usar strace -T e analisar a saída para ver quanto tempo cada syscall está interrompendo (já que não posso usar stap ).
O que eu encontrei é aberto, escrever e dup2 estão demorando mais do que os outros. Todos os três são normais, dado que eu quero criar muitos arquivos com conteúdo - então eu realmente não sei para onde posso ir em frente!
estatísticas de strace:
open 26,8320000000
write 11,5165000000
dup2 7,0665500000
NOTA: A pedido, posso carregar saídas de comandos como sar etc.
Desculpe pelo Inglês pobre, é 2 AM aqui, quando ninguém realmente se preocupa com o seu site. Obrigado antecipadamente.
UPDATE : mudamos as fontes de alimentação de ~ 400W para ~ 650W, e não sinto mais o atraso. No entanto, a latência ainda é alta o suficiente para ficar preocupada.
A saída de megacli showsummary a0 mostra uma BBU problemática:
Hardware
Controller
ProductName : ServeRAID M5015 SAS/SATA Controller(Bus 0, Dev 0)
SAS Address : xxxx
FW Package Version: 12.12.0-0047
Status : Need Attention
BBU
BBU Type : iBBU
Status : Replace Battery pack