O servidor não está lidando, as médias de carga da CPU aumentam para 33,0

Question

Basicamente, eu tenho um servidor com falha sob carga. É um site de notícias editorial que vê picos de tráfego irregulares. Estou arrancando meu cabelo tentando estabilizar a configuração LAMP.

Current Time: Wednesday, 14-Dec-2011 15:13:06 SAST
Restart Time: Wednesday, 14-Dec-2011 14:08:44 SAST
Parent Server Generation: 0
Server uptime: 1 hour 4 minutes 21 seconds
Total accesses: 52825 - Total Traffic: 530.2 MB
CPU Usage: u281.32 s20.44 cu0 cs0 - 7.82% CPU load
13.7 requests/sec - 140.6 kB/second - 10.3 kB/request
19 requests currently being processed, 13 idle workers

Eu sou louco ou deveria meu servidor dedicado estar facilitando a carne dessa carga?

• Intel i7
• 8 GB DDR3
• Soft raid 1
• CentOS6

As médias de carga normalmente são em torno de 3, mas duas vezes hoje subiu para 30+; despejou seus clientes e estabilizou de volta para 2.

'' top '' revela pouco interesse com o mysql sentado em 11% cpu.

Na sua opinião, isso é possivelmente um problema de hardware? Eu vejo a invasão talvez entupindo com uma interface ata sem resposta em um desses casos de carga ruim?

Quantos req / s você diria que é justo para uma caixa deste tamanho?

    

Answer 1

O número "load average" não é realmente carregado - é o número de threads no estado "em execução" ou "executável". Os tópicos supracitados podem estar aguardando que algo aconteça - operações de paginação ou I / O por exemplo (o que seria mau desempenho AE / S é tipicamente um recurso compartilhado e se um número de threads estiver esperando por ele , há boas chances de que ainda mais entrem na fila de espera).

Em uma configuração com um servidor MySQL em execução, vi números semelhantes devido a bloqueio contenção em uma tabela popular durante operações de atualização demoradas . Você pode verificar emitindo o comando SHOW PROCESSLIST para o seu servidor MySQL (o PHPMyAdmin tem isso exposto como uma função). A solução rápida e suja para isso foi habilitar atualizações de baixa prioridade na configuração do MySQL.

    

Answer 2

Você precisa obter métricas mais detalhadas para identificar o problema.

Eu costumo rever

• disco io
• uso de ram
• troca de uso
• uso de rede
• conexões / seg no apache
• consultas / s no banco de dados
• problemas de firewall
pilha de rede
• (por exemplo, espera de tempo, conectons abertos)

A partir daqui, eu trabalho nos logs do Apache, MySQL e do sistema.

Por fim, consulte os problemas específicos de aplicativos.

Algumas ferramentas:

• Munin ou Cacti (ou outra ferramenta para fornecer estatísticas detalhadas)
• Ferramentas Sysstat e empacotadas (iostat, vmstat, etc)
• Status estendido no Apache
• Registrar consultas lentas no MySQL
• Relatórios de cache para caches de opcode, memcache, etc.
• link para verificações de frontend
• Para problemas com aplicativos, alguns de meus clientes obtiveram sucesso com a New Relic

Com um bom kit de ferramentas e uma abordagem sistemática, você geralmente pode começar a desvendar o problema.

Alguns testes úteis:

• Acessar conteúdo estático (img ou css)
• Acesse uma página mundial phpinfo ou hello
• Acesse uma página do php com uma conexão de banco de dados simples e feche
• Acesse uma página do php com uma conexão de banco de dados, selecione, feche
• Acesse uma página do php com uma conexão de banco de dados escrita e feche
• Acesse seu aplicativo da web

Ao cronometrar cada um desses testes, você pode começar a desvendar onde a latência pode estar acontecendo. Eu tenho visto servidores altamente carregados retornarem conteúdo estático muito rapidamente. O tempo até o primeiro byte foi muito baixo. Isso sugere um problema na camada de aplicativo. Continuando a trabalhar com a pilha de aplicativos até encontrar a lentidão.

Apesar de tedioso, esse processo me serviu bem e, depois que você se acostumar, poderá passar por isso rapidamente.

    

Answer 3

Isso acontece regularmente? Ou seja, todos os dias você sabe quando isso acontecerá?

Tarefas Cron em execução nesse momento?

Quais processos (top ou htop devem mostrar) estão em execução?

Qual subsistema de disco você está executando? Tipo de RAID? Tipo de controlador? (em diferentes canais ...?)

A carga do servidor não é apenas o uso da CPU. Pode ser uma sobrecarga de rede ou sobrecarga do sistema de acionamento.

Você está verificando seus discos para ver se há algum problema nas unidades? Um possivelmente falhando?

Você precisará restringir exatamente o que está acontecendo, se o banco de dados estiver sufocado, você está recebendo um número real de acessos ao site, qual é o seu tráfego, se há mensagens nos registros, é o servidor executando um trabalho em lotes de algum tipo que é pesado no disco I / O ...? Qualquer uma dessas coisas pode causar um aumento no "carregamento" do servidor. Você precisará restringir onde e o que está indo a esse ponto. Se estiver acontecendo quase na mesma hora do dia, verifique os cronogramas e qualquer coisa que possa estar fazendo o serviço de limpeza no servidor, incluindo backups ou despejos de disco.

Se estiver relacionado a outra coisa ... talvez atualizando um tipo específico de notícia ... verifique seu uso de largura de banda. Verifique seus registros para ver se você está em algum tipo de verificação ou investigação de usuários mal-intencionados.

    

Answer 4

Escala, para o impaciente ou apenas preguiçoso:

• Resultados do banco de dados de cache (memcached) e material estático (verniz, nginx);
• Serviço de veiculação separado da veiculação do aplicativo (imagens, js, css, veiculação de um host diferente);
• DB separado do aplicativo;
• Carregar o saldo do acesso ao aplicativo em vários servidores;

Claro, você tem que fazer isso antes de checar seu servidor como Bart disse e tem certeza de que o servidor está fazendo o que pode. Quero dizer, se houver espaço para melhorar seu design atual, faça isso primeiro, mas mesmo nessa situação, o armazenamento em cache ajudará muito.