Htop no Linux: lendo a carga de um servidor sem se assustar com as cores.

Quando um servidor fica lento, htop Rapidamente dá a impressão de explicar tudo. Barras de CPU, memória, cores, uma lista de processos se movendo em todas as direções… e às vezes um impulso bastante perigoso: matar o primeiro processo que parece estar consumindo muitos recursos.

Recomendo a leitura do htop como ponto de partida. Ele ajuda a identificar possíveis problemas, mas não é uma fonte confiável para conclusões. Neste artigo, veremos o que verificar primeiro: uso da CPU, uso da memória, carga média, ordenação de processos e, mais importante, as verificações a serem realizadas antes de desligar um serviço de produção.

Instale e execute o htop no Linux.

Em muitas distribuições, o htop não vem instalado por padrão. No Debian ou Ubuntu, você pode adicioná-lo usando o APT:

sudo apt update
sudo apt install htop

No Fedora:

sudo dnf install htop

No Arch Linux:

sudo pacman -S htop

Em seguida, basta iniciar:

htop

Se você estiver conectado a um servidor remoto via SSH, abra o htop em uma sessão limpa. Evite realizar ações destrutivas a partir de uma sessão instável ou de um terminal que você possa fechar acidentalmente.

Leia as barras de CPU sem entrar em pânico.

Na parte superior da tela, o htop exibe uma barra para cada núcleo ou thread da CPU. Isso é útil para verificar se a carga está distribuída ou se um único núcleo está trabalhando em sua capacidade máxima.

Um breve pico de uso da CPU não é necessariamente um problema. Backups, compilações, verificações de antivírus ou compressões podem causar picos de uso por alguns segundos. O que mais me interessa é a duração do pico e o processo envolvido.

Antes de mexer em qualquer coisa, verifique também o número de processadores lógicos disponíveis:

nproc

Uma carga média de 4 em uma máquina com 8 threads não tem o mesmo significado que em um VPS pequeno com 1 vCPU. É uma distinção simples, mas evita muitas decisões ruins.

tempo de atividade

A ordem tempo de atividade Exibe os três valores médios de carga em intervalos de 1, 5 e 15 minutos. Se os três estiverem aumentando por um tempo, você tem um sinal mais forte do que um simples pico visto no htop.

Se você quiser aprofundar-se nesse ponto, o artigo sobre média de carga no Linux Essa leitura complementa bem o texto.

Utilização de memória: não confunda cache com saturação.

O uso de memória costuma ser motivo de preocupação. No Linux, uma parte significativa da RAM pode ser usada como cache de disco. Isso não é necessariamente ruim. O kernel libera esse cache quando os aplicativos precisam dele.

Para verificar fora do htop, execute:

grátis -h

Observe especialmente a coluna. disponívelSe o conforto se mantiver, a memória pode não ser o seu principal problema, mesmo que a barra superior pareça muito cheia.

No entanto, se a memória disponível diminuir, o espaço de swap aumentar e o servidor ficar lento, você precisará identificar o processo que está causando o inchaço. No htop, você pode classificar por memória com F6então escolha a coluna %MEM.

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | cabeça

Este comando fornece uma leitura rápida fora de uma interface interativa. Pode ser útil para solucionar problemas caso o htop não esteja instalado ou se você quiser copiar a saída para um ticket.

Analisando os processos para encontrar o verdadeiro culpado.

No htop, a lista inferior exibe os processos. As colunas mais úteis inicialmente são: PID, USUÁRIO, CPU%, %MEM, TEMPO+ E Comando.

Algumas coisas que você precisa saber:

• F6 Para escolher a coluna de classificação;
• F4 Para filtrar a lista;
• F5 Exibir a árvore de processos;
• F9 Enviar um sinal a um processo;
• q para sair do htop corretamente.

A visualização em árvore é muito útil. Ela permite ver se um processo que consome muitos recursos está sendo iniciado por um serviço, um script, um usuário SSH ou um processo filho de um servidor web.

Se você observar um processo Java, PHP, Python ou Node consumindo muitos recursos, não o encerre aleatoriamente. Primeiro, verifique a qual serviço ele pertence:

systemctl status nginx --no-pager
systemctl status php8.4-fpm --no-pager
systemctl status mariadb --no-pager

Naturalmente, adapte os nomes dos serviços ao seu servidor. Se você não sabe quais serviços estão em execução, consulte o artigo sobre Comandos systemctl para listar serviços do Linux É mais apropriado antes de prosseguirmos.

Antes de encerrar um processo, verifique os registros.

O botão mais tentador do htop é F9É usado para enviar um sinal a um processo. Tecnicamente, você pode matar um PID usando o htop. Na prática, geralmente é a última coisa que você faz, não a primeira.

Antes de desligar um serviço, verifique seus registros recentes:

sudo journalctl -u nginx -n 80 --no-pager

Se o serviço gravar em um arquivo dedicado, acompanhe o processo por alguns segundos:

sudo tail -f /var/log/nginx/error.log

Para esta seção, você também pode reler o artigo sobre monitoramento de logs de cauda e em tempo realIsso impede que você fique preso em frente ao htop sem contexto.

Se o processo pertencer a um serviço do systemd, uma reinicialização completa é preferível:

sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

Se você realmente precisa enviar um sinal para um PID, comece por PRAZO. Manter MATAR Para casos em que o processo para de responder completamente.

sudo kill -TERM 1234
sudo kill -KILL 1234

Substituir mil duzentos e trinta e quatro pelo PID real. E se você estiver em um banco de dados, armazenamento, servidor de produção ou em uma sessão de cliente ativa, espere mais trinta segundos antes de executar qualquer ação. Muitas vezes é aí que você evita uma falha grave.

Quando o htop não é suficiente

O Htop exibe os processos muito bem, mas não conta toda a história. Uma alta carga pode vir da CPU, da memória, de E/S de disco, da rede, de um serviço bloqueado ou de um pico normal de uso de um aplicativo.

Recuando um pouco:

vmstat 1 5
systemctl --falhou
journalctl -p aviso..alerta -b --no-pager

vmstat Fornece uma visão rápida dos tempos de espera da CPU, memória, swap e E/S. systemctl --falhou Lista as unidades com falha. jornalctl Permite identificar avisos da inicialização atual.

Se o problema envolver portas de rede ou um serviço que não está mais em execução, verifique também o que está realmente aberto. ss ou netstat no Linux.

Meu método rápido para lidar com um servidor lento.

Quando abro o htop em um servidor lento, recebo esta sequência de comandos:

• observe a média de carga com tempo de atividade e compare-o com o número de threads da CPU;
• verifique a memória disponível com grátis -h ;
• Ordene o htop por CPU e depois por memória;
• Identificar o departamento ou usuário responsável pelo processo;
• Leia os registros antes de reiniciar ou encerrar qualquer coisa;
• Execute uma reinicialização completa com o systemctl se o processo depender de um serviço.

O Htop é excelente para ver o que está acontecendo no momento. Mas a decisão correta raramente se baseia em uma única cor ou coluna. Considere o PID, o serviço, os logs e só então escolha a ação.

Para obter documentação de referência, você pode consultar o site oficial de htop, dela Repositório GitHube a página de manual de principal para conceitos relacionados a carga e processos.

sudo apt update && sudo apt upgrade