Leia avisos de memória e disco antes de atualizar.

Capture uma pequena linha de base com contexto

Use uma conta Linux autorizada a inspecionar a aplicação que você opera. Os comandos aqui inspecionam o estado; eles não removem arquivos nem redimensionam armazenamento. Alguns diretórios e journals precisam de acesso elevado. Substitua /var/lib/field-api, /opt/field-api e /opt/first-api por caminhos reais da aplicação, e confirme que esses caminhos existem antes de interpretar os resultados.

Registre o horário, a versão atual e a atividade: tráfego normal, um upload, uma tarefa de relatório ou um build de implantação. Faça outra leitura durante atividade comparável. Duas capturas de tela não relacionadas podem fazer uma máquina saudável parecer inconsistente. Se os usuários já estão afetados, capture a primeira pista útil do guia de falha de aplicação antes de fazer várias mudanças ao mesmo tempo.

Leia a memória disponível, depois inspecione a carga de trabalho

free -h
ps -eo pid,comm,rss --sort=-rss | head -n 12

Em free, a memória disponível estima o que poderia ser usado para novas aplicações sem swap. Ela considera o cache recuperável, então responde a uma pergunta diferente da memória “livre” completamente não utilizada. Veja o manual upstream do free. O Linux usa memória para cache de arquivos; um cache grande sozinho não é evidência de vazamento. A visão geral de memória do kernel explica por que cache e memória de aplicação coexistem.

Leitura ilustrativa, não uma medição do servidor: um host pequeno tem cerca de 1.9 GiB de memória utilizável, 80 MiB livres e 850 MiB disponíveis. O número baixo de memória livre sozinho não justifica um upgrade. Se a memória disponível cair repetidamente perto de zero durante um relatório, as requisições ficarem mais lentas e surgirem mensagens relevantes de alocação ou de falta de memória, essa evidência combinada merece investigação.

O ps comando lista o RSS dos processos em KiB, do maior para o menor. O RSS descreve a memória residente, não uma contabilidade completa de propriedade exclusiva; páginas compartilhadas podem aparecer em vários processos. Não some cada valor de RSS e trate o resultado como uso exato do host. A referência upstream do ps define RSS e ordenação. Registre o nome do processo e se seu consumo retorna ao nível anterior após o término da carga de trabalho.

O swap em uso pode refletir atividade anterior; ele não prova pressão atual por si só. Também distinga capacidade do host de limites de serviço ou contêiner. Um processo restringido pode falhar enquanto o host ainda tem memória disponível. Inspecione o limite configurado e o horário da falha antes de aumentar o tamanho da VPS. A referência do sistema de arquivos proc do kernel documenta os campos de memória por trás dessas observações.

Encontre o sistema de arquivos que está realmente enchendo

df -h / /opt/first-api
df -i / /opt/first-api

O primeiro comando informa o espaço nos sistemas de arquivos que contêm esses caminhos. O segundo informa inodes, que são registros do sistema de arquivos necessários para arquivos e diretórios. Uma carga de trabalho com muitos arquivos minúsculos pode esgotar inodes enquanto a capacidade em bytes permanece. Verifique o mount e ambos os tipos de capacidade, em vez de usar o tamanho da VPS inteira como seu único número. Veja o manual GNU do df.

Um caminho em um volume montado separadamente pode encher independentemente do sistema de arquivos raiz. Por outro lado, dois caminhos listados podem pertencer ao mesmo sistema de arquivos, então seu espaço disponível não é aditivo. Reservas de sistema de arquivos, cotas e camadas de armazenamento também podem afetar o que a aplicação consegue gravar. Uma única porcentagem exibida não identifica o responsável pelo crescimento.

Atribua o crescimento a logs, uploads ou artefatos

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du estima o espaço alocado em cada diretório. Aqui -x evita atravessar para outro sistema de arquivos, -h usa unidades legíveis e -d1 limita a profundidade exibida. Árvores grandes ainda podem levar tempo e atividade de disco para serem escaneadas. Erros de permissão significam que a visão está incompleta. Veja o manual GNU do du. O comando de journal informa o armazenamento do journal, incluindo arquivos ativos e arquivados, conforme documentado por journalctl.

Compare os maiores diretórios com sua finalidade:

• Logs: um erro repetido aumentou o volume, e a rotação está configurada?
• Uploads: os arquivos de usuário retidos estão crescendo conforme o esperado, e os uploads parciais abandonados estão contabilizados?
• Artefatos de release: builds antigos estão se acumulando além da política de rollback?
• Arquivos de banco de dados: as ferramentas próprias do banco de dados explicam o crescimento e as necessidades de manutenção?

Não exclua um diretório de banco de dados desconhecido nem use uma limpeza ampla de volume de contêiner como etapa de investigação. Identifique a propriedade, os requisitos de retenção e uma cópia recuperável primeiro. Se df e os totais de diretório discordarem substancialmente, inspecione limites de mount, erros de acesso e arquivos ainda mantidos abertos após exclusão com um operador experiente; excluir repetidamente arquivos visíveis pode não alcançar o espaço ocupado.

Transforme as leituras em uma próxima ação específica

Caso ilustrativo: a memória disponível permanece confortável, mas um diretório de uploads cresce cerca de 400 MiB em cada um de dois dias observados. O sistema de arquivos tem cerca de 2 GiB disponíveis. Dividir o espaço restante por esse crescimento de curto prazo sugere apenas cerca de cinco dias no mesmo ritmo, antes de considerar uma margem operacional. Isso é uma estimativa de planejamento, não uma previsão nem um prazo seguro para esperar; uploads e trabalhos temporários podem chegar de forma irregular.

A próxima ação é verificar a retenção de uploads e a demanda esperada, planejar armazenamento adicional se justificado e definir um alerta cedo o suficiente para agir. Mais RAM não resolveria essa constatação. Em outro caso, um build de implantação pode criar um breve pico de memória enquanto o serviço permanece pequeno; mover o build para fora da VPS poderia ser mais útil do que aumentar permanentemente o runtime.

Após uma mudança justificada, repita as mesmas leituras e uma ação da aplicação. Confirme que o espaço está realmente disponível e que os dados pretendidos ainda funcionam. Mantenha exclusão e redimensionamento como operações planejadas com etapas de recuperação, não como respostas automáticas a um número vermelho. Use o guia de orçamento de recursos para transformar uma necessidade demonstrada em escolhas de configuração, e pratique restauração antes de depender de uma limpeza ou migração.