"D-state" e load average fantasma

Recentemente, enfrentei um incidente crítico envolvendo a montagem de volumes de backup externos (NFS) em uma instância de produção. O sintoma era clássico, mas a causa raiz exigiu uma descida ao nível das syscalls para evitar um cascading failure (falha em cascata) completo no servidor.

O sistema apresentava um load average superior a 50, embora o uso global de CPU estivesse abaixo de 10%. Ao analisar utilitários como top e htop, notei que diversos processos de manutenção e backup (cpbackup e rsync) estavam presos no estado Uninterruptible Sleep (D state). O ponto de montagem NFS, destinado ao storage de backup externo, não respondia a um simples comando ls, travando indefinidamente o terminal da sessão de quem tentasse acessá-lo.

1. O que é o "d-state" e o load average fantasma?#

No Linux, processos marcados com o estado D (Uninterruptible Sleep) estão em uma suspensão profunda que ignora qualquer tentativa de sinalização do sistema operacional. Ao contrário do estado S (Interruptible Sleep), que responde a interrupções imediatas, um processo em D-state está travado no espaço do kernel aguardando o retorno de uma chamada de sistema (syscall) diretamente na camada física do driver de dispositivo ou do barramento de I/O.

Como os processos em estado ininterruptível estão tecnicamente prontos para processar assim que o recurso de hardware responder, o agendador do Linux (scheduler) os inclui na contagem de tarefas ativas na fila de execução (runqueue). Isso gera o fenômeno do Load Average Fantasma: a métrica de carga dispara para valores alarmantes sem que haja consumo real de CPU ou memória.

2. A opção de montagem `intr` está deprecada#

Um erro comum em runbooks legados de administração de sistemas é sugerir o uso da flag intr (interruptible) na montagem do NFS para permitir que o kernel interrompa as operações travadas.

O dilema do NFS: montagem hard vs soft#

Para evitar que processos fiquem presos permanentemente em D-state, você deve configurar corretamente os parâmetros de timeout da montagem:

Montagem hard (Padrão): Se o servidor NFS de destino cair, o cliente NFS insiste indefinidamente em refazer as operações RPC de escrita e leitura. Isso preserva de forma robusta a integridade e consistência dos arquivos, mas causa o travamento permanente de processos em estado D caso o storage remoto não responda.
Montagem soft: Se o servidor remoto cair, o cliente tenta restabelecer comunicação e, ao atingir o limite de timeout (timeo) e tentativas (retrans), o kernel retorna um erro de I/O (EIO) diretamente para a aplicação. Isso impede que os processos travem para sempre, porém pode levar a corrupções silenciosas de arquivos se o software cliente não souber tratar a falha de escrita.

Parâmetros finos de timeout do NFS#

timeo: Define o timeout limite para respostas em décimos de segundo (ex.: timeo=30 representa 3 segundos).
retrans: Define o número de tentativas de transmissão antes que o cliente reporte erro ou aviso de indisponibilidade.

Comandos de montagem recomendados para kernels modernos#

# OPÇÃO SOFT: Recomendada para backups em lote e logs (não crítico, evita travamento permanente de I/O)
mount -t nfs -o soft,timeo=30,retrans=3,rsize=32768,wsize=32768,nosuid IP_STORAGE:/export/backup /mnt/meu_backup

# OPÇÃO HARD CONTROLADA: Recomendada para arquivos de banco de dados (garante integridade de dados com tempo de timeout maior)
mount -t nfs -o hard,timeo=600,retrans=2,rsize=32768,wsize=32768,nosuid IP_STORAGE:/export/backup /mnt/meu_backup

3. Protocolo de backup antes de desmontar com `umount -l`#

Quando um ponto de montagem NFS congela, a reação imediata costuma ser forçar a desmontagem (umount -f) ou realizar um lazy unmount (umount -l).

Antes de forçar a desmontagem, execute as seguintes etapas de contenção e cópia de segurança:

Identifique processos travados acessando a montagem:

   # Listar arquivos abertos e descritores associados ao ponto de montagem NFS
   lsof +f -- /mnt/backup_ovh

Realize backup de arquivos críticos acessíveis na memória ou cache local:

   # Tentar empacotar os arquivos críticos do diretório antes do reset de I/O
   tar czf /root/pre-nfs-fix-backup.tar.gz /mnt/backup_ovh/critical-files/ 2>/dev/null

   # Ou executar uma sincronização incremental com timeout rígido de rede
   rsync -av --timeout=10 /mnt/backup_ovh/ /root/nfs-backup/ 2>/dev/null

4. Investigando o kernel e o servidor NFS remoto#

Se as syscalls estão travando, comece inspecionando os arquivos de montagem do kernel e valide a comunicação com a syscall stat:

# Inspecionar as montagens conforme registradas pelo kernel
cat /proc/mounts

# Rastrear a syscall stat() e verificar o retorno de erro de timeout (ETIMEDOUT)
strace -e trace=stat ls /mnt/backup_ovh

Triagem de saúde do servidor NFS#

Certifique-se de que o storage remoto de destino está saudável e aceitando conexões:

# 1. Testar conectividade e latência básica ICMP
ping -c 3 IP_STORAGE

# 2. Consultar o portmapper do servidor remoto
rpcinfo -p IP_STORAGE

# 3. Listar as pastas autorizadas e exportações ativas do servidor NFS
showmount -e IP_STORAGE

# 4. Validar portas TCP de comunicação usando Netcat
nc -zv IP_STORAGE 2049   # Porta nativa do NFS
nc -zv IP_STORAGE 111    # Porta do Portmapper (RPC bind)

5. Diagnóstico de rede, MTU e fragmentação#

Altas taxas de retransmissão RPC indicam que pacotes grandes de leitura e escrita (rsize/wsize) podem estar excedendo a capacidade de MTU da rota de rede, resultando em fragmentações de pacotes IP que são descartadas por firewalls intermediários.

Teste de fragmentação de pacote IP#

Para validar qual o tamanho máximo de pacote que passa sem fragmentação pela rota ativa de rede:

# Enviar pacote ICMP de 1472 bytes (payload de 1500 bytes com cabeçalho) forçando o bit de não fragmentação (DF)
ping -M do -s 1472 IP_STORAGE

Rastreabilidade de rotas e sockets ativos#

# Analisar a rota e possíveis gargalos de latência até o storage
traceroute IP_STORAGE

# Verificar o estado dos sockets TCP associados à comunicação do NFS
ss -tnp | grep -E "2049|111"

6. Verificação de versões do protocolo NFS#

Assegure que cliente e servidor estão conversando no mesmo nível de protocolo (NFSv3, NFSv4, NFSv4.1) para evitar comportamentos inesperados em locks de arquivos.

# Listar as versões do protocolo NFS compiladas e suportadas no cliente Linux
cat /proc/fs/nfsfs/versions

# Verificar as estatísticas de versão ativas do servidor NFS
nfsstat -s | head -5

# Verificar em qual versão e opções o NFS ativo está montado
mount | grep nfs

7. Relação com o PHP-FPM e i/o stall#

Em ambientes web, a inconsistência do NFS propaga-se rapidamente para a aplicação. Se um script PHP realiza a persistência de logs ou dumps de backup via file_put_contents() ou fwrite(), a syscall write() entra em estado bloqueado no kernel se os buffers de escrita estiverem cheios.

Sem a opção de timeout soft, os workers do PHP-FPM ficam presos aguardando a finalização da syscall e entram em D-state, exaurindo rapidamente a diretiva max_children. O servidor web passa a retornar erros de 502 Bad Gateway para todos os usuários legítimos porque o interpretador está sem recursos livres.

8. Verificação de outras montagens NFS e status de SELinux#

Audite se outras montagens de rede no servidor foram contaminadas pelo travamento de I/O em cascata:

# Listar todos os mounts remotos ativos no servidor
mount | grep nfs

# Verificar a resposta de espaço em disco de cada ponto montado
df -h | grep nfs

Verificação de permissões com o SELinux#

O SELinux pode bloquear a criação de canais de comunicação com storages remotos se as políticas necessárias não estiverem ativas:

# Verificar o status de policiamento do SELinux
getenforce

# Buscar negações AVC relacionadas ao serviço NFS nos logs do sistema
sudo ausearch -m avc -ts recent | grep -i "nfs"

# Visualizar o contexto de segurança das pastas do ponto de montagem
ls -Z /mnt/meu_backup/

9. Persistência de montagem e configuração do fstab#

Para garantir que a montagem seja automática e não trave o boot do sistema em cenários de indisponibilidade temporária de rede, adicione a entrada no /etc/fstab com a flag especial _netdev. Isso instrui o sistema operacional a aguardar a inicialização completa do stack de rede antes de tentar acoplar o volume NFS:

# Injetar a entrada persistente otimizada e resiliente de rede
echo "IP_STORAGE:/export/backup /mnt/meu_backup nfs soft,timeo=30,retrans=3,rsize=32768,wsize=32768,nosuid,_netdev 0 0" | sudo tee -a /etc/fstab

Para validar a sintaxe e a montagem sem reiniciar o servidor:

# Executar a montagem em lote a partir do arquivo fstab editado
sudo mount -a

10. Verificação pós-fix e homologação#

Após restabelecer a montagem com as opções otimizadas, valide a estabilidade do ponto de montagem e das métricas do servidor:

# 1. Validar a leitura física do diretório remoto
ls -la /mnt/meu_backup/

# 2. Executar teste de escrita e exclusão imediata de arquivo no storage
touch /mnt/meu_backup/test-file && rm /mnt/meu_backup/test-file

# 3. Certificar que o load average retornou aos parâmetros normais
uptime

# 4. Verificar se ainda restam processos travados em D-state no sistema
ps aux | awk '{if ($8 ~ /D/) print}'

# 5. Analisar as estatísticas de retransmissão RPC do cliente NFS
nfsstat -rc

Checklist: diagnóstico e correção de NFS freeze#

1. Diagnóstico e triagem#

[ ] Verificar a carga média de carga fantasma: uptime
[ ] Listar todos os processos ativos travados em D-state: ps aux | awk '{if ($8=="D") print}'
[ ] Rastrear travamentos de syscall de arquivos: strace -e trace=stat ls /mnt/backup_ovh
[ ] Inspecionar estatísticas de conexões pendentes do NFS: nfsstat -rc

2. Triagem do servidor NFS#

[ ] Testar resposta ICMP (ping) do servidor de storage: ping IP_STORAGE
[ ] Validar serviços ativos via portmapper remoto: rpcinfo -p IP_STORAGE
[ ] Listar pontos de exportação NFS válidos no storage: showmount -e IP_STORAGE
[ ] Checar portas TCP 2049 e 111 com Netcat: nc -zv IP_STORAGE 2049

3. Procedimento de backup e desmontagem segura#

[ ] Identificar processos com arquivos abertos no ponto congelado: lsof +f -- /mnt/backup_ovh
[ ] Executar backup de arquivos que ainda respondem em cache local via tar ou rsync com timeout.
[ ] Realizar a desmontagem lenta e segura das referências: umount -l /mnt/backup_ovh
[ ] Se houver processos residuais, aplicar SIGKILL suave com verificação de PID.

4. Diagnóstico de rede e protocolo#

[ ] Testar MTU e fragmentação de pacotes IP: ping -M do -s 1472 IP_STORAGE
[ ] Rastrear saltos de rede: traceroute IP_STORAGE
[ ] Consultar estatísticas de conexões NFS ativas do sistema: ss -tnp | grep -E "2049|111"
[ ] Validar versões de protocolo suportadas: cat /proc/fs/nfsfs/versions

5. Correção e montagem resiliente#

[ ] MANDATÓRIO: Remover referências ao parâmetro obsoleto/deprecado intr do script de montagem.
[ ] Definir montagem resiliente soft com controle fino de timeouts (timeo=30, retrans=3).
[ ] Ajustar tamanho de buffers de gravação e leitura (rsize=32768,wsize=32768) para mitigar fragmentação.
[ ] Testar montagem manual com as novas diretivas.

6. Persistência de sistema e segurança#

[ ] Adicionar entrada resiliente no /etc/fstab contendo a flag _netdev.
[ ] Testar a consistência do arquivo de tabela de mounts: sudo mount -a
[ ] Verificar se o SELinux está em Enforcement (getenforce) e buscar bloqueios do NFS no ausearch.
[ ] Validar contexto de segurança das pastas montadas (ls -Z).

7. Validação pós-fix#

[ ] Verificar se o load average reduziu e estabilizou.
[ ] Validar criação e deleção de arquivos no diretório NFS.
[ ] Confirmar que o interpretador do PHP-FPM não possui workers em D-state.
[ ] Monitorar o nfsstat para garantir zero taxas de retransmissão RPC.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Este post está licenciado sob CC BY-NC.