Descobrir o que está causando a lentidão de um servidor

Question

Eu tenho um cliente em potencial que tem um site php que funciona bem na maioria das vezes. No entanto, a cada semana, haverá um atraso (carga de página lenta). Estou certo de que há uma infinidade de coisas que podem estar causando isso (problemas de rede, instalação incorreta, um arquivo php específico, aumento da carga de tráfego). No entanto, preciso de uma maneira de deduzir o que está causando isso. Existe algum software de monitoramento de servidor feito especialmente para lidar com essas situações?

PS: O servidor é linux

    

Answer 1

Eu descobriria o seguinte:

• Essa "lentidão" afeta todos os usuários?
• A lentidão é para todo o site ou apenas um conjunto específico de funções dentro do site?
• Isso acontece na mesma hora todos os dias e no mesmo dia a cada semana?

Se a lentidão for sempre na sexta-feira na hora de desistir e o aplicativo for usado para que os usuários insiram os dados do cartão de horário da semana, pode ser simplesmente que o servidor precise de mais CPU / Memória e ou Largura de Banda para suportar a carga de todos os usuários de última hora. Basta dizer que esses tipos de padrões serão difíceis de rastrear sem conhecer os detalhes da aplicação e seus usuários e usos.

Para recomendar ferramentas, precisamos saber em qual sistema operacional seu aplicativo está sendo executado? Windows / IIS, Linux / Apache? No entanto, na minha experiência anedótica, a lentidão do site é causada por uma das poucas coisas:

• Programação ruim de banco de dados
  • SELECT * FROM TableXYZ
  • Consultas para colunas não indexadas
• Problemas do servidor
  • Memória insuficiente
  • Largura de banda insuficiente
    • Servidor - > Usuário
    • Servidor - > Banco de Dados

As coisas mais comuns para verificar (problemas relacionados ao desempenho) são

• servidor de banco de dados
  • CPU Load
  • Memória disponível
  • Comprimento da fila de disco (o disco IO do disco está maximizado?
• servidor da web
  • CPU Load
  • Uso da memória
  • Largura de banda para usuários finais
  • Largura de banda para o servidor de banco de dados

Answer 2

Você tem acesso ao shell?

O sysstat está instalado?

Se você tiver acesso ao shell, verifique se o sysstat está instalado e ativado. Espere uma hora ou mais para coletar dados e digite "sar" como root, na linha de comando. Se você vir dados, ótimo. Agora deixe isso. Leia os tutoriais sysstat ou sar no tempo médio. Quando você vê lag novamente, conecte, execute o sar, veja o que exatamente está diminuindo a velocidade quando. Ver exatamente quando e o que está sofrendo de fome (CPU / Memória / E / Rede) lhe dará uma idéia melhor do que ver.

    

Answer 3

Como você mede a desaceleração? Você usa ferramentas externas de monitoramento da web, como keynote ou alertfox? Isso seria útil para comparar com os logs internos.

    

Answer 4

Uma ótima ferramenta para monitoramento do sistema (seja ad-hoc na linha de comando ou para tendências se você configurá-lo para executar em segundo plano e registrar dados), é dstat . É a melhor ferramenta que encontrei para a linha de comando.

Um benefício é que sua única dependência é em Python, então você pode executá-lo diretamente de sua casa em um sistema ao qual você tem acesso limitado, e a maior parte da funcionalidade não requer raiz.

Aqui está um alias favorito para fornecer a você o uso em tempo real dos principais componentes (e dos processos de batida mais pesados) a cada segundo:

> which dstat-long
dstat-long      dstat -cdngm --top-cpu --top-mem

    

Answer 5

Para nós, no ambiente MSSQL, a opção de expansão automática de banco de dados ativada em um servidor de banco de dados ocupado pode causar uma desaceleração aleatória também. Durante o crescimento automático, a E / S de disco é muito pesada à medida que o arquivo é expandido, portanto, quaisquer transações em tempo real que ocorram durante esse período serão visivelmente mais lentas, especialmente se esse servidor já estiver sendo executado perto de seus limites de E / S. p>

Para resolver isso, simplesmente expandimos a quantidade de crescimento automático de banco de dados em MBs para um número ridiculamente grande, de modo que isso só ocorre uma vez por ano agora. Ainda uma desaceleração, mas isso não acontece toda semana agora.