solucionar memória lotando: identificar processo e resolver

16 min de leitura  ·  Guia técnico

solucionar memória do servidor lotando é o processo de confirmar se existe pressão real de RAM, listar os processos por consumo, identificar o serviço responsável e aplicar uma correção segura. Para identificar o processo que está usando memória demais no Linux e resolver sem derrubar aplicações críticas, siga estes passos:

1. Verifique se a memória está realmente em falta ou se é apenas cache do Linux.
2. Liste os processos por uso de RAM com top, htop ou ps.
3. Confirme o PID, o usuário e o serviço associado antes de encerrar qualquer processo.
4. Analise swap, logs do kernel e mensagens do OOM Killer.
5. Corrija a causa ajustando serviço, aplicação, cache, workers ou plano de recursos.

Pré-requisitos

• Acesso SSH ao servidor com usuário root ou usuário com sudo. Se precisar revisar o acesso, consulte Acessando servidores VPS Linux da AviraHost.
• Servidor Linux como Ubuntu 24.04 LTS, Debian 12, Rocky Linux 9 ou AlmaLinux 9.
• Permissão para consultar processos, serviços systemd e logs do kernel.
• Noções básicas de serviços como Nginx, Apache, PHP-FPM, MySQL, MariaDB, Redis, Docker ou serviços de e-mail.
• Antes de reiniciar serviços de produção, confirme se há janela de manutenção ou baixo tráfego.

Como solucionar memória do servidor lotando pelo diagnóstico inicial

O monitoramento de RAM no Linux deve começar separando memória realmente indisponível de memória usada como cache de disco. Em servidores Linux, é comum ver a coluna de memória usada alta mesmo quando ainda existe memória disponível para aplicações. Por isso, o primeiro passo não é matar processos, mas observar a linha available, o uso de swap e a carga do sistema.

1. Conecte-se ao servidor por SSH.
2. Confira o consumo geral de memória.
3. Verifique se a swap está sendo usada intensamente.
4. Compare memória disponível com lentidão percebida na aplicação.

free -h

Output esperado:
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       2.9Gi       180Mi       120Mi       760Mi       620Mi
Swap:          2.0Gi       480Mi       1.5Gi

Ao rodar este comando, você verá se a coluna available ainda tem folga. Se available estiver muito baixa e a swap estiver crescendo, há indício de pressão de memória. Se used estiver alto, mas available também estiver confortável, provavelmente o Linux está usando cache, o que não significa falha por si só.

uptime

Output esperado:
 14:32:10 up 8 days,  3:21,  1 user,  load average: 1.20, 1.48, 1.61

O load average ajuda a entender se a falta de memória está acompanhada de lentidão geral. Um servidor com pouca RAM disponível, swap em uso intenso e load subindo merece investigação imediata. Para uma visão mais ampla de performance, o artigo Dicas de Otimização de Servidores Linux complementa este diagnóstico.

Identificar processo consumindo memória no Linux

Identificar processo consumindo memória no Linux exige ordenar os processos pelo percentual de RAM e confirmar se o consumo vem de um serviço esperado ou de um crescimento anormal. Em produção, processos de banco de dados, PHP-FPM, Java, Node.js, containers Docker e servidores web podem aparecer no topo por motivos legítimos. O erro comum é encerrar o primeiro processo da lista sem entender o impacto.

1. Liste os maiores consumidores de memória.
2. Anote o PID, o usuário e o comando.
3. Compare com os serviços esperados no servidor.
4. Repita a verificação após alguns minutos para ver se o consumo continua crescendo.

ps aux --sort=-%mem | head -n 10

Output esperado:
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql       1180  8.2 42.1 2145000 1650000 ?    Sl   09:10  24:33 /usr/sbin/mysqld
www-data    2301 12.4 14.8  620000 580000 ?     S    14:02   1:20 php-fpm: pool www
www-data    2302 10.9 13.7  600000 540000 ?     S    14:02   1:10 php-fpm: pool www
root         901  1.1  5.2  420000 205000 ?     Ss   09:08   2:02 /usr/sbin/nginx

O campo RSS é especialmente útil porque representa memória residente em uso pelo processo. Se vários workers do mesmo serviço aparecem com consumo elevado, a causa pode estar em limite de workers, tráfego, cache, plugin, consulta lenta ou vazamento na aplicação.

top -o %MEM

Output esperado:
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
1180 mysql     20   0 2094m   1.6g   32000 S   8.2  42.1  24:33.10 mysqld
2301 www-data  20   0 605m    566m   22000 S  12.4  14.8   1:20.03 php-fpm
2302 www-data  20   0 586m    527m   21000 S  10.9  13.7   1:10.44 php-fpm

Dentro do top, use a ordenação por memória para observar se o mesmo PID permanece crescendo. Se preferir uma visão interativa mais amigável e o pacote estiver disponível na sua distribuição, o htop também pode ser usado para filtrar por usuário, árvore de processos e consumo individual.

solucionar memória do servidor lotando com confirmação do PID

Depois de encontrar o PID suspeito, confirme o comando real, o usuário e o caminho do executável. Essa etapa evita confundir um processo legítimo de banco de dados com um script travado ou um worker temporário.

ps -fp 1180

Output esperado:
UID          PID    PPID  C STIME TTY          TIME CMD
mysql       1180       1  8 09:10 ?        00:24:33 /usr/sbin/mysqld

Confirmar serviço responsável antes de encerrar processo

A análise de uso de memória por serviço reduz o risco de indisponibilidade. Um PID pode pertencer a um serviço controlado pelo systemd, a um processo filho do PHP-FPM, a um container Docker ou a uma tarefa executada por cron. Antes de parar qualquer coisa, descubra qual unidade ou aplicação está por trás do consumo.

1. Consulte detalhes do PID encontrado.
2. Verifique se ele pertence a um serviço systemd.
3. Confira se há múltiplos processos do mesmo pool ou aplicação.
4. Reinicie o serviço apenas quando fizer sentido operacional.

cat /proc/1180/status | head -n 20

Output esperado:
Name:	mysqld
Umask:	0022
State:	S sleeping
Tgid:	1180
Pid:	1180
PPid:	1
Uid:	112	112	112	112
VmRSS:	1650000 kB

O campo VmRSS confirma a memória residente consumida pelo processo. Se o processo pertence a MySQL, MariaDB 11.4, PostgreSQL ou Redis, interromper sem planejamento pode afetar transações, filas e sessões ativas. Em servidores web, reiniciar PHP-FPM pode encerrar requisições em andamento.

systemctl status mysql

Output esperado:
● mysql.service - MySQL Server
     Loaded: loaded
     Active: active running
   Main PID: 1180 mysqld

Atenção: comandos como kill, systemctl stop e systemctl restart podem interromper aplicações. Use-os somente depois de confirmar o serviço, avaliar o impacto e, se possível, comunicar usuários ou executar em horário de menor movimento.

systemctl restart mysql

Output esperado:
Sem saída em caso de sucesso. Confirme com:
systemctl status mysql

Quando o serviço suporta recarga de configuração sem reinício completo, prefira reload em vez de restart. Em serviços que não aceitam reload, o restart pode ser necessário, mas deve ser tratado como ação operacional sensível.

Verificar swap alta e OOM Killer no Linux

Swap alta no Linux indica que o sistema está movendo páginas de memória para disco, o que pode deixar aplicações lentas quando ocorre de forma intensa. Já o OOM Killer aparece quando o kernel não consegue atender alocações de memória e escolhe processos para encerrar. Esses sinais ajudam a diferenciar consumo elevado controlado de falta crítica de RAM.

1. Veja se há swap configurada e quanto está em uso.
2. Observe atividade de memória em tempo real.
3. Procure mensagens do kernel relacionadas a falta de memória.
4. Relacione o horário do evento com quedas de serviço.

swapon --show

Output esperado:
NAME      TYPE SIZE USED PRIO
/swapfile file   2G 512M   -2

Uso moderado de swap não prova problema sozinho. O alerta aumenta quando USED cresce continuamente, o servidor fica lento e os processos principais demoram a responder.

vmstat 1 5

Output esperado:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  1 524288 185000  84000 610000    0   12   120   240  900 1300 35 10 45 10  0
 3  1 526000 160000  83000 590000   20   48   180   410 1100 1600 42 12 34 12  0

As colunas si e so mostram entrada e saída de swap. Valores persistentes indicam que o servidor está dependendo do disco para compensar falta de RAM, o que pode degradar sites, bancos e painéis.

journalctl -k --no-pager | grep -i "out of memory\|killed process\|oom"

Output esperado:
kernel: Out of memory: Killed process 2301 php-fpm total-vm:620000kB, anon-rss:560000kB
kernel: oom_reaper: reaped process 2301 php-fpm

Se aparecerem mensagens com Out of memory, Killed process ou oom_reaper, o kernel encerrou processos para recuperar memória. Nesse caso, apenas reiniciar o serviço pode restaurar temporariamente, mas a correção real exige ajustar consumo, limites ou capacidade.

Corrigir consumo excessivo de RAM no servidor

Corrigir consumo excessivo de RAM no servidor depende do processo identificado. Não existe uma única configuração segura para todos os ambientes: um site em WordPress com PHP-FPM, uma API Node.js, um banco MySQL 8.0 e um servidor com containers Docker têm padrões de consumo diferentes. A decisão deve considerar tráfego real, quantidade de workers, cache, consultas, plugins, filas e limite do plano.

1. Se o consumo vem de PHP-FPM, revise pools, quantidade de workers e scripts que ficam presos.
2. Se vem de MySQL ou MariaDB, investigue consultas pesadas, buffers e conexões simultâneas.
3. Se vem de Nginx ou Apache, confira volume de conexões, logs e módulos ativos.
4. Se vem de Docker, avalie limites de memória por container e comportamento da aplicação.
5. Se o consumo acompanha crescimento legítimo de tráfego, planeje upgrade de recursos.

systemctl status php8.3-fpm

Output esperado:
● php8.3-fpm.service - The PHP 8.3 FastCGI Process Manager
     Loaded: loaded
     Active: active running
   Main PID: 1402 php-fpm8.3

Em PHP-FPM, muitos processos filhos consumindo memória podem indicar excesso de workers ou requisições lentas. Ajustar limites sem medir pode causar erro por falta de workers, então registre o comportamento antes e depois da mudança.

ps aux --sort=-rss | grep -E "php-fpm|mysqld|nginx|apache2" | head

Output esperado:
www-data  2301  8.0 14.8 620000 580000 ? S 14:02 1:20 php-fpm: pool www
mysql     1180  7.2 42.1 2145000 1650000 ? Sl 09:10 24:33 /usr/sbin/mysqld
root       901  1.1  5.2 420000 205000 ? Ss 09:08 2:02 nginx: master process

Se a memória cresce sem voltar ao normal mesmo com queda de tráfego, investigue vazamento de memória na aplicação, jobs em loop, plugins, filas ou consultas que retornam dados demais. Se o consumo for compatível com tráfego e recursos contratados, a solução pode ser otimizar a aplicação ou migrar para um plano com mais RAM.

Problemas comuns e como resolver

Sintoma: RAM aparece quase toda usada, mas o servidor não está lento

Causa: o Linux pode estar usando memória livre como cache de disco, e isso aparece como memória ocupada em algumas leituras. Solução: confira a coluna available no free -h antes de concluir que falta RAM. Se available estiver aceitável, sem swap intensa e sem lentidão, provavelmente não há emergência.

Sintoma: swap cresce, load aumenta e o site fica instável

Causa: um ou mais serviços estão consumindo mais memória do que o servidor suporta, forçando uso frequente de swap. Solução: liste processos com ps aux --sort=-%mem, confirme o serviço e reduza workers, conexões, jobs ou cache. Se a demanda for legítima, considere ampliar recursos.

Sintoma: serviço cai sozinho e volta após reiniciar

Causa: o OOM Killer pode ter encerrado o processo quando o kernel ficou sem memória disponível. Solução: verifique journalctl -k e procure por Out of memory, Killed process ou oom_reaper. Depois ajuste limites do serviço afetado ou investigue vazamento na aplicação.

Sintoma: um processo não encerra com kill normal

Causa: o processo pode estar preso em operação de I/O, aguardando disco ou em estado que não responde imediatamente ao sinal. Solução: aguarde alguns instantes, verifique estado com ps e prefira parar pelo systemctl quando for um serviço. Use kill -9 apenas como último recurso, pois ele não permite encerramento limpo.

Perguntas frequentes sobre solucionar memória do servidor lotando

Como descobrir qual processo está consumindo mais memória no Linux?

Use comandos como top, htop, ps aux --sort=-%mem ou smem para listar os processos por uso de RAM. O ideal é confirmar o PID, o usuário responsável e o serviço associado antes de encerrar qualquer processo. Também compare o resultado em momentos diferentes para identificar crescimento contínuo.

É seguro matar um processo que está usando muita memória?

Nem sempre. Antes de usar kill ou systemctl stop, verifique se o processo pertence a banco de dados, servidor web, PHP-FPM, email ou outro serviço crítico. Encerrar um processo essencial sem análise pode derrubar aplicações ou causar perda de operações em andamento.

Memória cheia no Linux significa necessariamente problema?

Não necessariamente, porque o Linux usa memória livre para cache de disco e isso pode aparecer como RAM ocupada. O alerta real acontece quando há pressão de memória, uso intenso de swap, processos sendo finalizados pelo OOM Killer ou serviços ficando lentos. Por isso, observe available, swap e logs antes de agir.

Como saber se o OOM Killer derrubou um processo?

Verifique os logs do kernel com journalctl -k, dmesg ou arquivos de log do sistema. Mensagens contendo Out of memory, Killed process ou oom_reaper indicam que o kernel encerrou um processo para tentar recuperar memória. Relacione o horário do log com a queda percebida na aplicação.

O que fazer quando a memória do servidor lota com frequência?

Identifique o serviço que cresce continuamente, revise limites de workers, pools e cache, e verifique se há vazamento de memória. Se o consumo for compatível com o tráfego real, considere ajustar a aplicação ou migrar para um plano com mais recursos. Evite apenas reiniciar serviços repetidamente sem investigar a causa.

Conclusão

• Comece verificando free -h, swap e load average para confirmar se existe pressão real de memória.
• Use ps, top e logs do kernel para identificar o PID, o usuário e o serviço responsável antes de encerrar qualquer processo.
• Corrija a causa raiz revisando workers, pools, consultas, containers, cache ou capacidade do servidor.

Leia também

• Checklist: como detectar disco cheio antes de derrubar o servidor
• Guia para resolver erro de memória no WordPress: diagnóstico e ampliação
• Guia para Configurar Monitoramento de Recursos com Prometheus no VPS Linux

Precisa de ajuda com memória do servidor lotando?

Se a memória do servidor chega ao limite com frequência, pode ser hora de revisar configuração, aplicação e recursos disponíveis. A AviraHost oferece opções de VPS para quem precisa de mais controle e capacidade para hospedar aplicações Linux.

Conheça os planos de Servidor VPS da AviraHost