17 min de leitura · Guia técnico
LAMP (Linux, Apache, MySQL, PHP) e LEMP (Linux, Nginx, MySQL/MariaDB, PHP) são as duas stacks de servidor web mais usadas em VPS Linux. A principal diferença está no servidor web: o Apache usa um processo ou thread por conexão, enquanto o Nginx usa um modelo orientado a eventos assíncrono, o que impacta diretamente o consumo de RAM em ambientes com pouca memória.
LAMP vs LEMP: qual stack roda melhor em VPS com 1 GB RAM
Em um VPS com apenas 1 GB de RAM, cada megabyte conta. A escolha entre LAMP e LEMP afeta diretamente quanto de memória sobra para o banco de dados, para o cache e para a própria aplicação. O Nginx, por padrão, consome menos memória em repouso e sob carga de conexões simultâneas do que o Apache com módulos carregados. Isso torna o LEMP a escolha mais comum para VPS de entrada, mas o LAMP ainda é válido quando configurado corretamente com PHP-FPM.
Este guia compara as duas stacks em termos de consumo de memória, configuração, compatibilidade com WordPress e casos de uso reais em servidores com recursos limitados.
Pré-requisitos
- Acesso root ou sudo ao VPS via SSH
- Distribuição Linux: Debian 12, Ubuntu 24.04 LTS ou AlmaLinux 9
- VPS com no mínimo 1 GB de RAM e 10 GB de disco
- Conhecimento básico de linha de comando Linux
- Nenhuma stack instalada previamente (para evitar conflitos de porta 80/443)
Arquitetura das stacks: como cada componente usa a memória
Entender o modelo de processo de cada servidor web é o ponto de partida para comparar o consumo de RAM entre LAMP e LEMP.
O Apache no modo padrão prefork cria um processo filho para cada conexão. Cada processo carrega o interpretador PHP via mod_php, o que significa que mesmo uma requisição simples de imagem ou CSS ocupa um processo com PHP na memória. Em um VPS com 1 GB de RAM, isso limita severamente o número de conexões simultâneas antes de o sistema começar a usar swap.
O Nginx usa um modelo orientado a eventos: um número fixo de workers (geralmente igual ao número de CPUs) atende milhares de conexões simultâneas sem criar novos processos. O PHP é processado externamente via PHP-FPM, um gerenciador de processos separado. Isso significa que conexões estáticas (imagens, CSS, JS) não consomem slots PHP, liberando memória para requisições dinâmicas.
A tabela abaixo resume as diferenças arquiteturais:
- Apache prefork + mod_php: 1 processo por conexão, PHP sempre carregado, alto consumo de RAM por worker (~20–30 MB por processo)
- Apache event + PHP-FPM: modelo de threads, PHP externo, consumo reduzido, mais próximo do Nginx
- Nginx + PHP-FPM: workers fixos, PHP externo, arquivos estáticos sem custo PHP, menor footprint de memória
Para verificar o consumo real de memória após instalar cada stack, use:
ps aux --sort=-%mem | head -20
Output esperado (exemplo com Nginx + PHP-FPM):
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
www-data 1234 0.0 1.2 12345 6789 ? S 10:00 0:00 nginx: worker process
www-data 1235 0.0 2.1 45678 12345 ? S 10:00 0:00 php-fpm: pool www
Instalando o LEMP no Debian 12: passo a passo com consumo de memória
A stack LEMP com Nginx 1.22 e PHP-FPM 8.2 no Debian 12 é uma das combinações mais eficientes para VPS com 1 GB de RAM. Siga os passos abaixo para instalar e medir o consumo real.
- Atualize o sistema e instale os pacotes base:
apt update && apt upgrade -y
apt install -y nginx php8.2-fpm php8.2-mysql mariadb-server
- Verifique o consumo de memória logo após a instalação:
free -m
Output esperado:
total used free shared buff/cache available
Mem: 985 312 198 12 474 661
Swap: 512 0 512
- Configure o pool PHP-FPM para consumo mínimo. Edite
/etc/php/8.2/fpm/pool.d/www.conf:
pm = ondemand
pm.max_children = 5
pm.process_idle_timeout = 10s
pm.max_requests = 200
- Reinicie os serviços e verifique o status:
systemctl restart nginx php8.2-fpm
systemctl status nginx php8.2-fpm
- Configure o MariaDB para baixo consumo. Edite
/etc/mysql/mariadb.conf.d/50-server.cnf:
innodb_buffer_pool_size = 128M
max_connections = 50
query_cache_size = 0
query_cache_type = 0
- Reinicie o MariaDB e verifique a memória total usada:
systemctl restart mariadb
free -m
Output esperado (stack LEMP completa em repouso):
total used free shared buff/cache available
Mem: 985 420 180 14 384 551
Com a stack LEMP configurada com pm = ondemand, o PHP-FPM só cria processos quando há requisições, liberando memória em períodos de baixo tráfego.
Instalando o LAMP no Debian 12: configuração otimizada para 1 GB RAM
O LAMP com Apache e PHP-FPM é uma alternativa viável quando você precisa de compatibilidade com .htaccess ou com aplicações que dependem de módulos específicos do Apache. A chave para rodar bem em 1 GB de RAM é abandonar o mod_php e usar o Apache no modo event com PHP-FPM.
- Instale o Apache, PHP-FPM e MariaDB:
apt update
apt install -y apache2 php8.2-fpm php8.2-mysql mariadb-server libapache2-mod-fcgid
- Desative o módulo
mpm_preforke ative ompm_eventcom proxy para PHP-FPM:
a2dismod mpm_prefork php8.2
a2enmod mpm_event proxy_fcgi setenvif
a2enconf php8.2-fpm
- Ajuste os parâmetros do MPM Event em
/etc/apache2/mods-available/mpm_event.conf:
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxRequestWorkers 50
MaxConnectionsPerChild 1000
- Reinicie o Apache e verifique o consumo:
systemctl restart apache2 php8.2-fpm
free -m
Output esperado (LAMP com mpm_event + PHP-FPM em repouso):
total used free shared buff/cache available
Mem: 985 460 150 15 374 510
Perceba que o LAMP com mpm_event consome cerca de 40 MB a mais em repouso do que o LEMP, principalmente porque o Apache carrega mais módulos por padrão. Para desativar módulos desnecessários:
a2dismod status autoindex negotiation
systemctl restart apache2
Comparativo direto: LAMP vs LEMP em VPS com 1 GB RAM
O consumo de memória em carga real é o critério mais importante para escolher entre as duas stacks em um VPS com recursos limitados. Os valores abaixo são referências de comportamento típico, não benchmarks absolutos — o consumo real varia conforme a aplicação, o número de conexões e as configurações específicas.
- Nginx em repouso: ~5–10 MB por worker process
- Apache mpm_event em repouso: ~15–25 MB por processo pai + threads
- PHP-FPM (ambas as stacks): ~20–30 MB por processo filho ativo
- MariaDB com innodb_buffer_pool_size = 128M: ~150–180 MB
- Memória disponível para aplicação (LEMP): ~400–500 MB com 5 workers PHP-FPM
- Memória disponível para aplicação (LAMP): ~350–450 MB com configuração equivalente
Quando escolher LEMP:
- Sites com alto volume de arquivos estáticos (imagens, CSS, JS)
- APIs REST com muitas conexões simultâneas de curta duração
- WordPress em VPS com 1 GB de RAM (com OPcache ativado)
- Aplicações Node.js ou Python servidas via proxy reverso
Quando escolher LAMP:
- Aplicações legadas que dependem de
.htaccesscom regras complexas - CMSs que não têm documentação de configuração para Nginx
- Ambientes onde a equipe já tem experiência consolidada com Apache
- Quando módulos Apache específicos (como
mod_rewritecom lógica complexa) são necessários
Para aprofundar a comparação entre servidores web, consulte o artigo Dicas de Otimização de Servidores Linux para ajustes adicionais de kernel e sistema.
Configurando WordPress no LEMP com 1 GB RAM: ajustes essenciais
O WordPress no LEMP exige uma configuração de bloco de servidor Nginx diferente do Apache, pois não há suporte nativo a .htaccess. O bloco try_files substitui as regras de reescrita do WordPress.
Crie o arquivo de configuração do site em /etc/nginx/sites-available/meusite.conf:
server {
listen 80;
server_name meusite.com.br www.meusite.com.br;
root /var/www/meusite;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
}
location ~ /\.ht {
deny all;
}
}
Ative o site e recarregue o Nginx:
ln -s /etc/nginx/sites-available/meusite.conf /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx
Output esperado:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Ative o OPcache no PHP para reduzir o uso de CPU e memória em requisições repetidas. Edite /etc/php/8.2/fpm/php.ini:
opcache.enable=1
opcache.memory_consumption=64
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
Reinicie o PHP-FPM após a alteração:
systemctl restart php8.2-fpm
Se você está migrando um site existente para este ambiente, o artigo Configurando um Servidor Linux para Hospedagem de Sites cobre os passos de preparação do ambiente antes da migração.
Monitorando o consumo de memória das stacks em tempo real
Após instalar qualquer stack, monitorar o uso de memória sob carga real é essencial para validar se a configuração está adequada para o VPS com 1 GB de RAM.
Para verificar o consumo por processo em tempo real:
watch -n 2 'ps aux --sort=-%mem | head -15'
Para verificar o consumo específico do PHP-FPM:
ps aux | grep php-fpm | awk '{sum += $6} END {print sum/1024 " MB"}'
Output esperado (5 workers PHP-FPM ativos):
145.3 MB
Para verificar se o sistema está usando swap (sinal de que a RAM está esgotada):
vmstat 1 5
Output esperado (sistema saudável, sem swap ativo):
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 198456 12345 374123 0 0 1 2 45 120 2 1 97 0 0
Se os valores de si (swap in) e so (swap out) forem maiores que zero consistentemente, a stack está consumindo mais RAM do que o disponível. Nesse caso, reduza pm.max_children no PHP-FPM ou diminua o innodb_buffer_pool_size do MariaDB.
Problemas comuns e como resolver
Sintoma: Nginx retorna erro 502 Bad Gateway ao processar PHP
Causa: O Nginx não consegue se comunicar com o PHP-FPM porque o socket Unix ou a porta TCP está incorreta na configuração do bloco de servidor, ou o serviço PHP-FPM não está em execução.
Solução: Verifique se o PHP-FPM está rodando com systemctl status php8.2-fpm. Confirme o caminho do socket em /etc/php/8.2/fpm/pool.d/www.conf (linha listen =) e certifique-se de que o valor em fastcgi_pass no Nginx corresponde exatamente ao mesmo caminho. Reinicie ambos os serviços após corrigir.
Sintoma: Apache consome toda a RAM disponível após algumas horas
Causa: O Apache está rodando no modo prefork com mod_php, criando processos PHP para cada conexão, incluindo requisições de arquivos estáticos. O valor de MaxRequestWorkers pode estar alto demais para 1 GB de RAM.
Solução: Migre para mpm_event com PHP-FPM conforme descrito neste guia. Se precisar manter o prefork, reduza MaxRequestWorkers para 20–30 e adicione MaxConnectionsPerChild 500 para liberar memória de processos antigos periodicamente.
Sintoma: WordPress retorna erro 404 em todas as páginas exceto a home no Nginx
Causa: A configuração do bloco Nginx não tem a diretiva try_files $uri $uri/ /index.php?$args; correta, ou o arquivo .htaccess do WordPress está sendo ignorado (o que é esperado no Nginx, mas a regra equivalente precisa estar no bloco de servidor).
Solução: Adicione o bloco location / com try_files conforme o exemplo deste guia. Verifique também se o root aponta para o diretório correto onde o WordPress está instalado e se as permissões do diretório permitem leitura pelo usuário www-data.
Sintoma: MariaDB não inicia após reduzir innodb_buffer_pool_size
Causa: O valor configurado pode estar abaixo do mínimo aceito, ou há um erro de sintaxe no arquivo de configuração.
Solução: Verifique os logs com journalctl -u mariadb --no-pager -n 50. O valor mínimo recomendado para innodb_buffer_pool_size é 5 MB, mas valores abaixo de 64 MB podem degradar a performance. Para VPS com 1 GB, use 128 MB como ponto de partida.
Sintoma: PHP-FPM cria muitos processos e esgota a RAM
Causa: O parâmetro pm está configurado como static ou dynamic com valores altos de pm.max_children, fazendo com que o PHP-FPM pré-aloque processos mesmo sem tráfego.
Solução: Use pm = ondemand para VPS com 1 GB de RAM. Isso garante que processos PHP só sejam criados quando há requisições ativas. Configure também pm.process_idle_timeout = 10s para liberar processos ociosos rapidamente.
Perguntas frequentes sobre LAMP vs LEMP
Qual a diferença entre LAMP e LEMP?
LAMP usa Linux, Apache, MySQL e PHP, enquanto LEMP substitui o Apache pelo Nginx (pronunciado "engine-x", daí o "E"). A principal diferença prática é o servidor web: o Apache usa um processo ou thread por conexão, enquanto o Nginx usa um modelo orientado a eventos assíncrono, consumindo menos RAM em cargas com muitas conexões simultâneas.
LAMP ou LEMP: qual consome menos memória RAM?
Em geral, o LEMP consome menos RAM porque o Nginx tem um footprint de memória menor que o Apache com módulos carregados. Em um VPS com 1 GB de RAM, o Nginx com PHP-FPM costuma deixar mais memória disponível para o banco de dados e a aplicação do que o Apache com mod_php ou mod_fcgid. A diferença em repouso costuma ser de 40 a 80 MB, o que é significativo em ambientes com pouca memória.
Posso usar PHP-FPM com Apache no LAMP?
Sim. O Apache pode ser configurado com PHP-FPM via mod_proxy_fcgi, o que melhora o isolamento de processos e reduz o consumo de memória em relação ao mod_php clássico. Essa configuração aproxima o desempenho do LAMP ao do LEMP, mas o Nginx ainda tende a ser mais eficiente em conexões estáticas e keep-alive. Para ativar, use a2enmod proxy_fcgi setenvif e a2enconf php8.2-fpm.
LEMP funciona bem com WordPress em VPS de 1 GB?
Sim. O LEMP com Nginx, PHP-FPM e MariaDB é uma combinação amplamente usada para WordPress em VPS com pouca RAM. É recomendável configurar um pool PHP-FPM com pm = ondemand ou pm = dynamic com limites baixos, além de ativar OPcache, para manter o consumo de memória sob controle. Com essa configuração, o WordPress roda de forma estável com 5 a 8 workers PHP-FPM dentro do limite de 1 GB.
Qual stack é mais fácil de configurar para iniciantes?
O LAMP com Apache tende a ser mais familiar para iniciantes porque o Apache usa arquivos .htaccess que muitos CMSs (como WordPress e Joomla) já configuram automaticamente. No LEMP, as regras de reescrita precisam ser traduzidas para blocos try_files no Nginx, o que exige um passo extra de configuração manual. Para quem está começando e precisa de compatibilidade imediata com CMSs populares, o LAMP com mpm_event e PHP-FPM é um bom ponto de partida.
Conclusão
- Para VPS com 1 GB de RAM, o LEMP é a escolha mais eficiente: o Nginx consome menos memória em repouso e sob carga, especialmente em sites com muitos arquivos estáticos ou conexões simultâneas.
- O LAMP ainda é válido com a configuração correta: use
mpm_eventcom PHP-FPM em vez depreforkcommod_php, desative módulos desnecessários e ajusteMaxRequestWorkerspara o limite de RAM disponível. - Em ambas as stacks, o PHP-FPM com
pm = ondemande OPcache ativado é obrigatório para manter o consumo de memória sob controle em ambientes com pouca RAM.
Leia também
- Otimizar o Carregamento de Sites em VPS Linux e Servidor Dedicado com HTTP/2
- Passo a passo para configurar Nginx com PHP-FPM no VPS Linux: Guia Completo
- Comparativo: Apache vs. Nginx para Servidores Linux – Qual Escolher para Seu Projeto?
Precisa de ajuda com sua stack web?
Configurar LAMP ou LEMP em um VPS com recursos limitados exige ajustes finos que vão além da instalação padrão. Um VPS bem dimensionado e configurado pode rodar WordPress, APIs e múltiplos sites com estabilidade mesmo com 1 GB de RAM.
Conheça os planos de VPS da AviraHost e escolha o ambiente ideal para sua stack