Não estou escrevendo isto como uma avaliação negativa da FDCServers. Também não pretendo dizer se alguém deve ou não comprar um VPS deles. Tive um servidor, um workload e uma sequência específica de problemas. Isso não é suficiente para julgar uma empresa de hospedagem inteira.
É simplesmente um episódio do meu cotidiano como desenvolvedor. O VPS havia funcionado normalmente por algum tempo e já tinha transferido mais de 3 TB de tráfego. Então uma carga comum começou a gerar atrasos extremos. As páginas podiam demorar muito para responder ou terminar completamente em timeout. No início, suspeitei do que normalmente se suspeita: aplicação, Nginx, memória, rede, limites de conexão ou carga excessiva. As métricas do Linux apontavam para outro lugar.
O VPS não começou lento
Entre os incidentes, a máquina podia parecer completamente saudável. Em um período normal, não havia processos em D-state, o CPU iowait estava por volta de 0%, a latência do disco em cerca de 2–4 ms e o I/O PSI praticamente em zero:
D-state processes: 0
CPU iowait: ~0%
disk latency: ~2–4 ms
I/O PSI some: 0.04
I/O PSI full: 0.04Se eu tivesse conectado apenas naquele momento e verificado top, free -h, df -h e systemctl status nginx, provavelmente teria concluído que o VPS estava normal. Então o workload habitual voltou e o estado da máquina mudou drasticamente.
Leituras de 18,7 segundos mudaram a investigação
Uma das amostras de iostat mais fortes foi:
r_await = 18744 ms
f_await = 53561 ms
aqu-sz = 128.54
util = 100.10%
read = 88 KB/sOs números precisam ser lidos em conjunto. As leituras concluídas apresentavam latência média de aproximadamente 18,7 segundos. A latência de flush era de cerca de 53,6 segundos. A fila média de I/O estava acima de 128, enquanto o throughput útil de leitura era de apenas 88 KB/s. Não era simplesmente um disco ocupado movimentando muitos dados. O caminho de storage gastava um tempo enorme esperando as operações terminarem.
iowait e PSI mostraram pressão de I/O em todo o sistema
Nos piores períodos, vmstat mostrava 4–9 processos bloqueados, CPU iowait em torno de 97–100% e CPU idle em 0%. iowait não significa que a aplicação esteja usando toda a CPU. Significa que trabalho útil está esperando operações de I/O pendentes.
Linux Pressure Stall Information deixou a situação ainda mais clara:
I/O PSI some avg10 = 99.14
I/O PSI full avg10 = 95.55Em reproduções posteriores, full chegou perto de 98%. A utilização do disco diz que um dispositivo está ocupado; PSI mostra o quanto o workload está sendo efetivamente interrompido por aquele recurso. Pressão de I/O sustentada na faixa de 95–98% não é uma pequena regressão de performance.
D-state e kernel stacks apontaram para baixo da aplicação
Depois verifiquei quais processos estavam bloqueados. Ao mesmo tempo eu via jbd2, systemd-journald, workers do Nginx, processos de cache do Nginx e outras atividades de filesystem em D-state. Se apenas a minha aplicação estivesse travada, eu investigaria a aplicação. Quando Nginx, o journal do sistema e o journal do EXT4 bloqueiam juntos, storage passa a ser a dependência comum mais evidente.
Os caminhos de journaling do EXT4 incluíam:
wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transactionOs workers do Nginx esperavam em leituras comuns de arquivos:
folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64Em certo momento, o kernel informou que uma tarefa do Nginx estava bloqueada havia mais de 122 segundos. O Nginx ainda podia aparecer como active, mas isso não significava que seus workers conseguissem concluir trabalho útil. running e saudável são estados diferentes.
Uma resposta do backend em 3 ms separou a aplicação do filesystem
A comparação mais clara foi entre Nginx e o backend local da aplicação. Requisições pelo Nginx retornavam HTTP=000 por timeout de conexão ou TLS. Uma requisição direta ao backend terminava em cerca de 3 ms:
connect = 0.000423 s
TTFB = 0.003063 s
total = 0.003139 sO status HTTP exato não era importante nesse teste. O backend aceitava a conexão, processava a requisição e produzia uma resposta quase imediatamente. Ao mesmo tempo, os workers do Nginx eram vistos esperando leituras de EXT4. Isso separou a execução normal da aplicação do caminho dependente do filesystem à sua frente.
O problema era reproduzível e também podia desaparecer
Antes de uma reprodução, a máquina parecia normal:
HTTP: 200
D-state: 0
CPU iowait: 3%
r_await: ~1.18 ms
I/O PSI full: ~2.95%Cerca de meio minuto depois:
D-state: 4
CPU iowait: 91%
CPU idle: 0%
I/O PSI some: 86.11%
I/O PSI full: 78.02%
r_await: 236.50 ms
HTTP: 000Mais tarde, o CPU iowait chegou a 96–100%, o I/O PSI full se aproximou de 98%, a fila HTTPS chegou a 512 e as verificações HTTP continuavam falhando. Isso era uma evidência muito mais útil do que simplesmente dizer que o VPS parecia lento.
Ao remover o workload, a transição inversa podia acontecer rapidamente:
D-state: 0
CPU iowait: 6%
r_await: ~0.98 ms
queue depth: ~0.07
HTTP: 200É por isso que problemas de storage intermitentes são difíceis de analisar depois do fato. O provedor pode verificar o servidor depois da recuperação e realmente encontrar latência normal. Isso não explica o que aconteceu dez minutos antes. Timestamps UTC precisos se tornaram essenciais.
Duas métricas que podem enganar: await=0 e espaço livre
Em alguns intervalos ruins eu via r_await = 0 enquanto iowait estava alto, processos estavam em D-state, requisições continuavam in-flight e quase nenhuma leitura terminava. Estatísticas de latência se baseiam em I/O concluído. Se uma operação permanece travada e não termina na janela de amostragem, ela não pode contribuir para a média das operações concluídas. Portanto, zero nem sempre significa um disco instantâneo.
Também considerei o preenchimento do disco. Mais tarde o filesystem ficou mais cheio do que eu normalmente permitiria, mas o mesmo tipo de falha já tinha aparecido quando o root filesystem estava apenas cerca de 24% utilizado. Naquele momento havia aproximadamente 1,2 GiB de RAM disponível, uso de inodes em torno de 5% e a interface de rede não mostrava erros nem pacotes descartados. O preenchimento do disco não explicava todo o incidente.
O que consegui provar e o que não consegui
De dentro do VPS eu podia observar a aplicação, Linux VFS, EXT4 e o virtual block device. Depois disso começa a infraestrutura do provedor: virtualização, storage distribuído, rede de storage, dispositivos físicos, scheduling e outras camadas que eu não consigo inspecionar a partir do guest.
Por isso não posso afirmar honestamente que um SSD físico específico estava quebrado, nem apontar um storage node, caminho de rede ou componente de virtualização específico como root cause.
O que posso dizer é mais restrito, porém bem sustentado: o caminho de storage virtual apresentado ao meu guest Linux entrava repetidamente em estados nos quais operações comuns de I/O do filesystem demoravam segundos ou não terminavam em um tempo razoável. A evidência veio de iostat, PSI, D-state, kernel wait stacks, esperas EXT4/jbd2, esperas de filesystem do Nginx, profundidade de fila e tempos das requisições. Isso era suficiente para o diagnóstico de engenharia de que eu precisava, mas não para identificar uma causa física.
Por que os mais de 3 TB anteriores não contradizem os stalls posteriores
Isso me confundiu no começo. Se o storage tinha problemas, como o VPS havia transferido vários terabytes com sucesso?
Porque tráfego de rede não é a mesma coisa que I/O físico de disco. Um arquivo pode ser lido uma vez do backing storage, permanecer no Linux page cache e depois ser servido muitas vezes da memória. Três terabytes transferidos pela rede não significam três terabytes de leituras físicas únicas.
As condições de infraestrutura também mudam com o tempo: estado do cache, carga do storage, filas, host placement e outros workloads podem variar. Um VPS funcionar normalmente ontem não garante comportamento idêntico do storage hoje.
Por fim, parei de esperar por uma root cause mais profunda
Coletei timestamps exatos, vmstat, iostat, PSI, snapshots de processos bloqueados, kernel stacks, esperas de filesystem, profundidade de filas e tempos HTTP. Enviei os diagnósticos à FDCServers e esperei por uma explicação mais profunda no nível da infraestrutura.
Esperei bastante. Por fim, parei. Do meu lado, já sabia o suficiente para tomar uma decisão operacional: o problema era reproduzível, grave, visível abaixo da camada da aplicação e a causa física estava fora da visibilidade do meu VPS.
Pedi reembolso e a FDCServers devolveu o dinheiro
Enviei à FDCServers um resumo dos problemas e dos diagnósticos coletados, pedi o cancelamento do serviço e solicitei reembolso. Eles devolveram o dinheiro.
Portanto, a história não termina em uma longa disputa financeira. Esperei uma explicação técnica definitiva, decidi que não queria esperar mais, enviei as evidências que tinha e pedi meu dinheiro de volta. A FDCServers devolveu.
O que mudei depois disso
O resultado útil não foi decidir se uma empresa de hosting é boa ou ruim. Foi mudar a maneira como diagnostico servidores Linux lentos.
Ainda uso top, free -h e df -h, mas hoje chego muito mais cedo a:
date -u
uptime
cat /proc/pressure/io
cat /proc/pressure/memory
cat /proc/pressure/cpu
vmstat 1 10
iostat -x 1 10
ps -eo state,pid,ppid,etime,wchan:50,comm,args | awk 'NR==1 || $1 ~ /^D/'
ss -lntp
journalctl -k --since '30 min ago' --no-pagerTambém testo caminhos de request separadamente sempre que possível: requisição pública, Nginx local, backend direto, filesystem e métricas de block device. A pergunta deixou de ser apenas por que o servidor está lento. Agora é: em qual camada o trabalho útil deixa de ser concluído?
Quando possível, capturo as evidências antes do reboot. Um reboot pode restaurar o serviço, mas também pode apagar exatamente o D-state, PSI, as filas e a latência que tornam um incidente intermitente diagnosticável.
Consideração final
Não comprei um VPS da FDCServers porque queria material para um artigo sobre hosting. Eu precisava de um servidor com bastante banda. Por algum tempo foi exatamente isso que tive: ele processou carga real e transferiu mais de três terabytes.
Depois, o workload normal começou a produzir de forma reproduzível iowait de até 100%, I/O PSI quase em 100%, leituras de até 18,7 segundos, flush latency acima de 53 segundos, filas grandes, Nginx bloqueado em leituras do filesystem e EXT4/jbd2 esperando I/O.
Nunca descobri qual componente físico ou host-side causou isso, e não preciso fingir que descobri. Identifiquei a camada em que a falha se manifestava, reuni evidências suficientes para diferenciá-la de um problema da aplicação, parei de esperar por uma explicação mais profunda e pedi meu dinheiro de volta. A FDCServers reembolsou.
Isso não é um veredito sobre todo VPS da FDCServers. É apenas um lembrete bem documentado de que um serviço pode aparecer como active, um processo como running, enquanto a máquina passa quase todo o tempo útil esperando pelo storage.