Otimizando memória e eliminando o esgotamento de SWAP em servidores Linux com aaPanel

Manter uma VPS rodando painéis de gerenciamento web como o aaPanel parece simples à primeira vista: alguns cliques, stacks instaladas e tudo pronto. Porém, quando você coloca a mão na massa em um ambiente de produção (em uma VM com Rocky Linux 8.10 e 11 GB de RAM), a configuração padrão das stacks rapidamente cobra o preço em latência de I/O e exaustão de recursos.

Recentemente, enfrentei um cenário clássico de gargalo: o sistema indicava memória livre e disponível, mas a partição de SWAP estava quase no teto (1.76 GB usados de 2.0 GB). Isso gerava I/O constante em disco e microtravamentos nas respostas HTTP das aplicações.

Abaixo, compartilho o diagnóstico, a análise técnica de cada serviço envolvido e os passos práticos que tomei para derrubar o consumo ativo de memória de 3.29 GB para 2.1 GB e zerar o SWAP.

1. O diagnóstico: onde estava o gargalo?#

O primeiro passo foi inspecionar o uso de memória e a partição de swap com os utilitários padrão do Linux:

free -h
vmstat 1 5

A saída do free -h revelava o sintoma:

               total        used        free      shared  buff/cache   available
Mem:            11Gi       3.29Gi       4.82Gi       184Mi       3.01Gi       7.65Gi
Swap:          2.0Gi       1.76Gi       244Mi

Mesmo com mais de 7.6 GB disponíveis na RAM física, o kernel despejava páginas anônimas para o swap. Para descobrir exatamente quais processos estavam consumindo memória residente (RSS) e empurrando blocos para o disco, utilizei este comando:

ps aux --sort=-%mem | awk 'NR<=15{print $2, $4, $6/1024 " MB", $11}'

Os maiores consumidores identificados foram:

1. mysqld / mariadbd: Alocando mais de 1.4 GB de buffer pool sem necessidade para o volume atual de tráfego.
2. PHP-FPM (múltiplas versões): Vários pools configurados em modo dynamic mantendo dezenas de workers ociosos na memória.
3. Serviço de Background do aaPanel (BT-Task e Python): Processos de monitoramento retendo cache de métricas.
4. Redis: Sem limite rígido de maxmemory, retendo chaves expiradas em RAM.

2. Ajustando o MySQL / MariaDB (innodb buffer pool)#

No aaPanel, o MySQL costuma ser instalado com um template pré-calculado com base na RAM total detectada na instalação, o que nem sempre faz sentido se a máquina divide recursos com múltiplos serviços.

Abra o arquivo de configuração do MySQL em /etc/my.cnf:

[mysqld]
# Ajustado para carga real da VM (anteriormente em 1536M)
innodb_buffer_pool_size = 512M
innodb_log_buffer_size = 16M
max_connections = 120
key_buffer_size = 32M
table_open_cache = 400

Após salvar, reinicie o serviço e valide o consumo de memória:

systemctl restart mysqld
systemctl status mysqld --no-pager

Essa mudança liberou imediatamente quase 900 MB de memória residente sem prejudicar o tempo de resposta das consultas.

3. Contendo pools ociosos do PHP-FPM#

Se você tem mais de uma versão do PHP instalada (por exemplo, PHP 7.4 para sistemas legados e PHP 8.2 ou 8.3 para novas aplicações), o aaPanel inicia daemons separados para cada versão.

Acesse a pasta de configurações do PHP no aaPanel (ex.: /www/server/php/82/etc/php-fpm.d/www.conf ou equivalente) e ajuste o gerenciador de processos:

[www]
pm = ondemand
pm.max_children = 20
pm.process_idle_timeout = 15s
pm.max_requests = 500

A diretiva pm = ondemand faz com que o master do PHP-FPM não crie workers previamente. Eles só são instanciados quando chega uma requisição HTTP real e são destruídos após 15 segundos de inatividade, devolvendo a RAM para o sistema operacional.

Reinicie os serviços do PHP:

/etc/init.d/php-fpm-82 reload
/etc/init.d/php-fpm-74 reload

4. Definindo limite de memória e política de evicção no Redis#

Se o Redis estiver ativo no aaPanel sem limites explícitos, ele pode crescer indefinidamente. Edite /www/server/redis/redis.conf:

maxmemory 256mb
maxmemory-policy allkeys-lru

Isso impede que o cache ultrapasse 256 MB e força o descarte das chaves menos usadas quando o teto for atingido.

/etc/init.d/redis restart

5. Ajustando parâmetros de kernel: swappiness e cache pressure#

Com os serviços contidos, o passo decisivo foi ensinar ao kernel Linux quando ele deve realmente recorrer ao swap. No Rocky Linux 8 o padrão é 30; em distribuições como Debian e Ubuntu é 60 — em ambos os casos, ainda é agressivo quando há RAM folgada, tornando o ajuste para 10 ideal para essa carga.

Edite o arquivo /etc/sysctl.d/99-memory-tuning.conf:

# Reduz a agressividade do swap (só swappa em extrema pressão de RAM)
vm.swappiness = 10

# Mantém caches de arquivos e diretórios na RAM por mais tempo
vm.vfs_cache_pressure = 50

# Evita que dirty pages acumulem demais antes do flush em disco
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

Aplique as mudanças em tempo real sem reiniciar o servidor:

sysctl --system

6. Limpando o SWAP com segurança#

Com a memória RAM agora livre e com mais de 8 GB disponíveis, o swap ainda guardava os 1.76 GB de páginas antigas em disco. Para esvaziar o swap e forçar o kernel a carregar as páginas ativas de volta para a RAM, execute o ciclo de swap:

# Desativa o swap (joga tudo de volta para a RAM disponível)
swapoff -a

# Reativa o swap com estado zerado
swapon -a

Nota: Só execute swapoff -a se o free -h indicar que a memória RAM livre (available) é substancialmente maior do que a quantidade usada no swap, caso contrário o OOM Killer pode ser disparado.

Recomendações de produção#

Depois de aplicar esses passos na VM, o novo status no free -h estabilizou em:

               total        used        free      shared  buff/cache   available
Mem:            11Gi       2.10Gi       6.15Gi       110Mi       2.87Gi       8.85Gi
Swap:          2.0Gi          0B        2.0Gi

Ao otimizar os serviços individualmente (MySQL, PHP-FPM, Redis) em vez de confiar cegamente nas automações dos painéis de controle, a latência causada pelo I/O de swap desapareceu e sobraram mais de 8.8 GB de RAM livre para absorver picos de tráfego.

Se você opera servidores Linux com painéis semelhantes (como CloudPanel, cPanel ou aaPanel), audite periodicamente os pools do PHP e a swappiness do kernel: essa combinação costuma ser a principal responsável por lentidões silenciosas em produção.

Conclusão#

Neste artigo compartilhei o passo a passo que reduziu o consumo ativo da VM de 3.29 GB para 2.1 GB e zerou o swap: conter o buffer pool do MySQL, trocar os pools do PHP-FPM para ondemand, limitar o Redis com maxmemory e ensinar o kernel a só swappar sob pressão real.

Veja também

DevOps Quando o VS code remote e o antigravity quase derrubaram meu servidor: anatomia de um thrashing de memória

Banco de Dados Como um SELECT COUNT(*) no LiveZilla derrubou o MySQL por max_connections (e como mitiguei)

Infraestrutura Rodando fastpanel e aaPanel no Podman (Rocky Linux): o pesadelo do UID mapping e soluções reais

Este post está licenciado sob CC BY-NC.