Inspeção de Processos

Q: lsof não encontrado no container Alpine?

Use ss -tlnp ou instale lsof apenas na imagem de depuração - não no Dockerfile de produção, a menos que aprovado.

Q: É seguro matar o PID 1 no container?

Não. O Kubernetes reinicia o pod. Reduza a réplica ou use kubectl delete pod para uma reinicialização limpa após o esvaziamento.

top, htop e lsof para diagnosticar conflitos de porta, processos Node descontrolados e pressão de recursos em hosts Linux executando APIs Node.js.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# Porta em uso (EADDRINUSE)
lsof -i :3000
# ou
ss -tlnp 'sport = :3000'
 
# Parada graciosa
kill -TERM <PID>
sleep 5
kill -KILL <PID>   # apenas se ainda estiver em execução
 
# Snapshot de CPU/memória
top -b -n 1 | head -20
ps aux | grep node

Quando usar isso:

Desenvolvimento local: Error: listen EADDRINUSE: address already in use :::3000
Produção: limitação de CPU ou mortes por limite de memória do pod
Suspeita de processo Node zumbi após execução de teste falhada
Múltiplos workers e API na mesma VM - quem é o dono de qual porta?

Exemplo de Trabalho

Conflito de porta no laptop do desenvolvedor

$ npm run dev
Error: listen EADDRINUSE: address already in use :::3000
 
$ lsof -i :3000
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node    48291  dev   23u  IPv6 0t...      0t0  TCP *:3000 (LISTEN)
 
$ kill -TERM 48291
$ npm run dev   # bem-sucedido

Prefira kill -TERM (SIGTERM) para que os hooks de desligamento do Fastify/Express sejam executados
kill -9 apenas quando o processo ignorar SIGTERM após 10s

Inspeção de pod de produção (Kubernetes)

# Encontrar pod
kubectl get pods -l app=orders-api
 
# OOM e motivo da reinicialização
kubectl describe pod orders-api-7f8b9c-xyz | grep -A5 "Last State"
 
# Top dentro do container (se a imagem tiver procps)
kubectl exec -it orders-api-7f8b9c-xyz -- top -b -n 1 | head -15
 
# Lista de processos
kubectl exec orders-api-7f8b9c-xyz -- ps aux

# Trecho típico do describe
Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

Código de saída 137 geralmente significa kill OOM (128 + 9)
Compare memory.limit do container com --max-old-space-size do Node, se definido

Processos de API e worker separados

ps aux | grep node
# node dist/server.js          ← API porta 3000
# node dist/workers/email.js   ← sem porta de escuta, CPU alta durante o batch

Workers sem HTTP não devem aparecer em lsof -i :3000
CPU alta do worker: verifique a concorrência do BullMQ e o tamanho do payload do job

Dicas do htop

htop
# Vista em árvore F5 - veja o PID 1 do container pai
# F6 ordena por MEM% ou CPU%
# Filtrar: F4 digite "node"

CPU single-threaded em 100% em um núcleo pode ser uma paralisação do event loop (trabalho síncrono)
Aumento de memória sem aumento de tráfego sugere vazamento - veja Skill de Triagem de Incidentes

Comparação

Ferramenta	Melhor para
lsof	Qual PID possui a porta 3000
ss	Resumo de sockets sem instalar lsof
top	Snapshot rápido de CPU/memória (todo servidor)
htop	Ordenação interativa e vista em árvore
kubectl describe	OOMKilled, contagem de reinicialização, limites

FAQs

lsof não encontrado no container Alpine?

Use ss -tlnp ou instale lsof apenas na imagem de depuração - não no Dockerfile de produção, a menos que aprovado.

Node mostra muitas threads no top - normal?

Sim. O pool de threads libuv e os workers V8 criam threads. Preocupe-se com memória RSS e atraso do event loop, não apenas com a contagem de threads.

É seguro matar o PID 1 no container?

Não. O Kubernetes reinicia o pod. Reduza a réplica ou use kubectl delete pod para uma reinicialização limpa após o esvaziamento.

Relacionados

Noções Básicas de CLI para Node - curl, jq, ss
Melhores Práticas de CLI do Linux - SIGTERM antes de SIGKILL
Resposta ao OOM Killer - heap vs RSS
Noções Básicas de Operações de Runtime - desligamento gracioso

Versões da Stack: Esta página foi escrita para Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 e NestJS 11.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# Porta em uso (EADDRINUSE)
lsof -i :3000
# ou
ss -tlnp 'sport = :3000'
 
# Parada graciosa
kill -TERM <PID>
sleep 5
kill -KILL <PID>   # apenas se ainda estiver em execução
 
# Snapshot de CPU/memória
top -b -n 1 | head -20
ps aux | grep node

Quando usar isso:

Desenvolvimento local: Error: listen EADDRINUSE: address already in use :::3000
Produção: limitação de CPU ou mortes por limite de memória do pod
Suspeita de processo Node zumbi após execução de teste falhada
Múltiplos workers e API na mesma VM - quem é o dono de qual porta?

Exemplo de Trabalho

Conflito de porta no laptop do desenvolvedor

$ npm run dev
Error: listen EADDRINUSE: address already in use :::3000
 
$ lsof -i :3000
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node    48291  dev   23u  IPv6 0t...      0t0  TCP *:3000 (LISTEN)
 
$ kill -TERM 48291
$ npm run dev   # bem-sucedido

Prefira kill -TERM (SIGTERM) para que os hooks de desligamento do Fastify/Express sejam executados
kill -9 apenas quando o processo ignorar SIGTERM após 10s

Inspeção de pod de produção (Kubernetes)

# Encontrar pod
kubectl get pods -l app=orders-api
 
# OOM e motivo da reinicialização
kubectl describe pod orders-api-7f8b9c-xyz | grep -A5 "Last State"
 
# Top dentro do container (se a imagem tiver procps)
kubectl exec -it orders-api-7f8b9c-xyz -- top -b -n 1 | head -15
 
# Lista de processos
kubectl exec orders-api-7f8b9c-xyz -- ps aux

# Trecho típico do describe
Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

Código de saída 137 geralmente significa kill OOM (128 + 9)
Compare memory.limit do container com --max-old-space-size do Node, se definido

Processos de API e worker separados

ps aux | grep node
# node dist/server.js          ← API porta 3000
# node dist/workers/email.js   ← sem porta de escuta, CPU alta durante o batch

Workers sem HTTP não devem aparecer em lsof -i :3000
CPU alta do worker: verifique a concorrência do BullMQ e o tamanho do payload do job

Dicas do htop

htop
# Vista em árvore F5 - veja o PID 1 do container pai
# F6 ordena por MEM% ou CPU%
# Filtrar: F4 digite "node"

CPU single-threaded em 100% em um núcleo pode ser uma paralisação do event loop (trabalho síncrono)
Aumento de memória sem aumento de tráfego sugere vazamento - veja Skill de Triagem de Incidentes

Comparação

Ferramenta	Melhor para
lsof	Qual PID possui a porta 3000
ss	Resumo de sockets sem instalar lsof
top	Snapshot rápido de CPU/memória (todo servidor)
htop	Ordenação interativa e vista em árvore
kubectl describe	OOMKilled, contagem de reinicialização, limites

FAQs

lsof não encontrado no container Alpine?

Use ss -tlnp ou instale lsof apenas na imagem de depuração - não no Dockerfile de produção, a menos que aprovado.

Node mostra muitas threads no top - normal?

Sim. O pool de threads libuv e os workers V8 criam threads. Preocupe-se com memória RSS e atraso do event loop, não apenas com a contagem de threads.

É seguro matar o PID 1 no container?

Não. O Kubernetes reinicia o pod. Reduza a réplica ou use kubectl delete pod para uma reinicialização limpa após o esvaziamento.

Relacionados

Noções Básicas de CLI para Node - curl, jq, ss
Melhores Práticas de CLI do Linux - SIGTERM antes de SIGKILL
Resposta ao OOM Killer - heap vs RSS
Noções Básicas de Operações de Runtime - desligamento gracioso

Versões da Stack: Esta página foi escrita para Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 e NestJS 11.

Inspeção de Processos

Buscar na documentação

Inspeção de Processos