Gerenciamento de Processos e Recursos
ps, htop, sinais, nohup e limites de recursos no Linux - gerencie workers web Python, processos Celery e scripts de longa execução sem zumbis órfãos ou OOM kills.
Receita
pgrep -af "uvicorn|celery|gunicorn"
kill -TERM <pid>
sleep 5
kill -KILL <pid> # apenas se ainda estiver em execução
htop -p <pid>Quando usar isso:
- Implantação de uvicorn duplicado na mesma porta
- Vazamento de memória do worker precisa de reinicialização
- Desligamento gracioso antes da janela de manutenção
- Diagnosticar pico de CPU de loop descontrolado
Exemplo de Trabalho
# Encontra o mestre e os workers do billing-api
pgrep -af gunicorn
# Recarregamento gracioso (se USR2/HUP configurado) ou TERM
sudo kill -TERM "$(pgrep -f 'gunicorn.*billing-api' | head -1)"
sleep 10
sudo ss -tlnp | grep 8000
# Verifica arquivos abertos para vazamento de conexão
PID=
O que isso demonstra:
pgrep -afmostra a linha de comando completa para processos Python- TERM permite o fechamento gracioso do FastAPI/Gunicorn
- KILL apenas após o tempo limite
- Inspeção de
/procpara vazamentos de fd
Mergulho Profundo
Como Funciona
- Sinais - SIGTERM para desligamento educado; SIGKILL imediato; SIGUSR1/2 específicos da aplicação.
- Pai/filho - O mestre do Gunicorn gera workers; matar o mestre para reciclar todos.
- OOM killer - O Linux mata o processo com alto RSS sob pressão de memória.
- cgroups - Limites de memória/CPU de contêineres no Docker/K8s.
Tabela de Referência de Sinais
| Sinal | Efeito no serviço Python |
|---|---|
| SIGTERM | Uvicorn/Gunicorn para de aceitar; drena requisições |
| SIGINT | Igual a Ctrl+C em desenvolvimento em primeiro plano |
| SIGHUP | Recarrega a configuração em alguns daemons |
| SIGKILL | Morte imediata - sem blocos finally |
Notas Python
# app registra um manipulador SIGTERM para limpeza
import signal
def handle_term(signum, frame):
close_db_pool()
signal.signal(signal.SIGTERM, handle_term)Armadilhas
- SIGKILL primeiro - Descarta transações HTTP e de banco de dados em andamento. Correção: TERM, espere, depois KILL.
- Matar PID errado do pgrep - Padrão muito amplo corresponde a dois aplicativos. Correção: verifique a linha de comando em
ps -fp. - nohup em produção - Cria órfãos na desconexão SSH sem rotação de logs. Correção: unidade systemd.
- Processos zumbis - Processo pai não está coletando filhos. Correção: reinicie o supervisor pai.
- Ignorar dmesg do OOM - Reinícios misteriosos. Correção:
dmesg -T | rg -i oom. - ulimit muito baixo - "Muitos arquivos abertos" sob carga. Correção:
LimitNOFILEno systemd.
Alternativas
| Alternativa | Use Quando | Não Use Quando |
|---|---|---|
| systemd restart | Serviços de produção | Experimento local rápido |
| Docker stop | Período de graça do contêiner | VM bare metal |
| Kubernetes delete pod | Roll orquestrado | Solução de problemas SSH |
| py-spy | Amostragem de Python travado | Reinicialização simples é suficiente |
FAQs
Quanto tempo esperar após SIGTERM?
Corresponde ao tempo limite de drenagem do balanceador de carga upstream - frequentemente 10-30s para APIs.
Múltiplos workers uvicorn?
Um processo por CPU com --workers N sob gunicorn; cada um aparece em pgrep.
Desligamento em quente do Celery?
celery control shutdown ou TERM worker; permita que as tarefas acks_late terminem.
nice/ionice para trabalhos em lote?
nice -n 10 uv run python batch.py reduz a contenção de CPU com a API na mesma VM.
cgroups v2 memória máxima?
systemd-run -p MemoryMax=2G ... limita o worker descontrolado em um host compartilhado.
strace quando?
Último recurso de desempenho/depuração - sobrecarga enorme; tente py-spy primeiro.
lsof vs ss?
ss para portas de escuta; lsof -p para arquivos/sockets abertos por PID.
Carga média vs CPU?
Alta carga com CPU baixa pode ser espera de IO - verifique iostat.
Filho defunct zumbi?
Identifique o pai com ps -o ppid= -p ZPID; reinicie o processo pai.
Memória livre no Linux?
A coluna available em free -h é mais importante do que a leitura de cache free.
Relacionados
- Fundamentos de Sysadmin - systemd
- SSH e Trabalho Remoto - kill remoto
- Implantando FastAPI - layout do gunicorn
- Fundamentos de Desempenho - profiling
Versões da Stack: Esta página foi escrita para Python 3.14.0 (estável 3.14, manutenção 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+ e uv 0.6+.