Perfil de desempenho do servidor Linux - como ver o que causou alta carga

4

Se um servidor estiver com carga alta, uso as ferramentas superiores e semelhantes para solucionar o motivo. No entanto, isso só será efetivo se eu puder analisar enquanto o servidor estiver com o problema.

Quais são algumas boas ferramentas para encontrar a causa raiz da alta carga do servidor em tempos anteriores? Por exemplo, eu estava planejando colocar em um cron job para salvar a saída 'top', estatísticas do servidor apache, lista de processos do mysql, etc a cada 5 minutos. Mas isso não parece muito elegante, imaginando se alguém criou alguns utilitários para realizar isso já.

    
por mark 06.09.2010 / 16:43

5 respostas

5

Para monitoramento contínuo, você pode considerar a instalação de munin . Ele coletará informações a cada 5 minutos e gerará gráficos que permitirão ver onde estão os gargalos. Eu também uso sar , que pode ser executado em modo de segundo plano, coletando dados no disco. Isso fornece informações bastante detalhadas sobre o gargalo. Para quais processos foram executados no passado, você precisará do pacote de contabilidade do processo.

    
por 06.09.2010 / 17:03
1

Sua solução não-elegante é realmente boa sem configurar consoles de monitoramento separados (pense em traps SNMP). Se você estiver executando um sistema de estilo RHEL / CentOS, certifique-se de ter instalado o 'sysstat' (e ligado) para coletar estatísticas contínuas sobre CPU, memória, E / S de disco e similares. (veja /etc/sysconfig/sysstat.* arquivos de configuração para sintonizar).

Uma vez que você tenha as estatísticas básicas para você, ele pode ser usado para identificar quando a tendência de carga ocorre (então, além de ver alta CPU, sua fila de processamento está backup? você vê grandes falhas na paginação? como está sua utilização de troca? ?) que você pode então correlacionar com suas listas do tipo 'mysqladmin proc stat' e assim por diante. Se for uma pilha LAMP, pegue o total de processos httpd e faça uma soma / divisão rápida para descobrir também o tamanho médio do processo a ser gravado. Habilite seu log de consultas lentas no MySQL para, então, prender esses bad boys e procurar algumas tabelas que precisem de índices.

Às vezes, a tecnologia não é má tecnologia. :) Por que usar uma motosserra quando uma faca serve.

    
por 06.09.2010 / 16:52
1

Eu gosto do collectd mas recentemente comecei a brincar com pcp (performance co-pilot). Tem alguns recursos interessantes para diagnóstico histórico. [1]: link

    
por 07.09.2010 / 05:06
0

Também pode querer olhar para collectd, como uma alternativa munin.

    
por 06.09.2010 / 17:49
0

em cima .

Ele complementa o top / htop, porque pode coletar estatísticas ao longo do tempo.

    
por 07.09.2010 / 10:04