Como Limitar CPU por Processo no Linux com cgroups (Guia Completo)

📌 Fundamentos + Base Técnica Profunda

🧩 Introdução: Por que você PRECISA limitar CPU por processo

Em ambientes Linux modernos — principalmente em VPS, servidores dedicados e cloud — o uso de CPU precisa ser tratado como um recurso crítico.

Ao contrário do que muitos iniciantes pensam, o Linux não limita automaticamente o uso de CPU por processo. Isso significa que qualquer aplicação pode consumir todos os recursos disponíveis se tiver demanda suficiente.

É exatamente por isso que aprender a limitar CPU por processo não é apenas uma otimização — é uma necessidade.

Imagine um cenário real:

• Um site WordPress recebe um pico de tráfego
• O PHP-FPM começa a spawnar múltiplos workers
• Cada worker consome CPU intensamente
• Em segundos, o servidor chega a 100% de CPU

Resultado:

• Outros sites ficam lentos
• APIs param de responder
• Painéis como DirectAdmin travam
• Usuários começam a abandonar o site

Tudo isso poderia ser evitado se você tivesse configurado corretamente como limitar CPU por processo.

Limitar o uso de CPU por processo é essencial para manter a estabilidade do sistema. Para entender o cenário completo, veja o guia de performance de servidores Linux.

⚙️ Como o Linux distribui CPU (entenda antes de limitar)

Antes de aplicar qualquer limitação, você precisa entender como o Linux distribui CPU.

O kernel usa um scheduler chamado CFS (Completely Fair Scheduler).

Esse scheduler tenta dividir o tempo de CPU de forma justa entre processos ativos. Porém, existe um detalhe crítico:

👉 “Justo” não significa “limitado”.

Se apenas um processo estiver ativo, ele pode usar 100% da CPU sem nenhuma restrição.

Se vários processos estiverem competindo, o kernel distribui — mas ainda assim sem limites rígidos.

Ou seja:

• O Linux distribui CPU
• Mas não impõe limites por padrão

É exatamente aqui que entra o conceito de limitar CPU por processo.

O controle de CPU deve ser feito com base em análise do sistema. Veja também:

• como identificar processos com alto uso de CPU
• como interpretar load average
• como monitorar com sar

🧠 O que são cgroups (control groups)

Os cgroups são um recurso do kernel Linux que permite controlar o uso de recursos por grupos de processos.

Eles são extremamente poderosos e permitem:

• Limitar CPU por processo
• Controlar uso de memória
• Restringir I/O de disco
• Isolar aplicações

Na prática, os cgroups funcionam como uma camada de controle entre o kernel e os processos.

Quando você usa cgroups para limitar CPU por processo, você está dizendo:

“Esse conjunto de processos só pode usar X% da CPU, independentemente da carga do sistema.”

⚙️ Entendendo o conceito de quota de CPU

O controle de CPU nos cgroups não é feito por “porcentagem direta”.

Ele funciona com base em dois parâmetros:

• Período (period)
• Quota (quota)

Exemplo clássico:

• Período: 100000 (100ms)
• Quota: 50000

Isso significa que o processo pode usar CPU por 50ms dentro de cada janela de 100ms.

Resultado:

👉 50% de CPU

Esse modelo é extremamente eficiente e permite granularidade fina ao limitar CPU por processo.

⚙️ cgroups v1 vs cgroups v2

Hoje existem duas versões:

🔹 cgroups v1 (antigo)

• Mais complexo
• Configuração separada por recurso
• Menos intuitivo

🔹 cgroups v2 (moderno)

• Interface unificada
• Mais simples
• Melhor integração com systemd

👉 Se você está em:

• AlmaLinux 8+
• Ubuntu 20+
• Debian 11+

Você provavelmente já usa v2.

🔍 Como verificar sua versão

mount | grep cgroup

Se aparecer:

cgroup2 on /sys/fs/cgroup

Você está usando a versão moderna.

⚙️ Criando seu primeiro controle de CPU

Agora vamos para a prática de limitar CPU por processo.

📁 Criar grupo

sudo mkdir /sys/fs/cgroup/limitado

🎯 Definir limite de CPU

echo "50000 100000" | sudo tee /sys/fs/cgroup/limitado/cpu.max

Aqui você já aplicou uma política para limitar CPU por processo.

🔗 Adicionar processo ao grupo

ps aux | grep nome_processo

Depois:

echo PID | sudo tee /sys/fs/cgroup/limitado/cgroup.procs

📊 O que acontece depois disso?

Quando você aplica essa configuração, o kernel começa a controlar o processo.

Sempre que ele tenta ultrapassar o limite definido:

• Ele é pausado temporariamente
• Aguarda o próximo ciclo
• Retoma execução

Esse mecanismo é chamado de CPU throttling.

O consumo descontrolado de CPU pode afetar todo o servidor. Confira como melhorar a performance de servidores Linux

🧠 Por que isso é melhor que “matar processo”?

Muitos administradores iniciantes usam:

kill -9 PID

Mas isso resolve apenas o sintoma.

Já ao limitar CPU por processo, você:

• Mantém o serviço funcionando
• Evita impacto global
• Garante estabilidade contínua

⚠️ Limitações do método manual

Embora funcione, usar cgroups diretamente tem limitações:

• Não é persistente após reboot
• Difícil de gerenciar em larga escala
• Não cobre automaticamente processos filhos

Por isso, em produção, o ideal é usar systemd.

📌 Quando você DEVE limitar CPU por processo

Você deve aplicar essa técnica quando:

🔥 Alto consumo de CPU recorrente

Se um serviço constantemente chega a 100%, ele precisa de limite.

🔥 Ambiente multi-tenant

Se você tem vários clientes no mesmo servidor, isso é obrigatório.

🔥 Aplicações imprevisíveis

Exemplo:

• Plugins WordPress
• Scripts externos
• Crawlers

🔥 Ambientes de produção críticos

Qualquer ambiente que não pode cair deve usar controle de CPU.

📊 Impacto direto no seu servidor

Ao implementar corretamente limitar CPU por processo, você vai notar:

✅ Redução de load average

O sistema fica mais equilibrado.

✅ Melhor tempo de resposta

Serviços continuam disponíveis mesmo sob carga.

✅ Isolamento de problemas

Um erro não afeta todo o servidor.

✅ Estabilidade geral

Menos quedas, menos travamentos.

🧠 Conceito chave para guardar

👉 Limitar CPU por processo não é sobre reduzir performance — é sobre distribuir corretamente os recursos.

🔥 Encerramento da Parte 1

Nesta primeira parte, você aprendeu:

• Por que limitar CPU é essencial
• Como o Linux gerencia CPU
• O que são cgroups
• Como funciona o controle de CPU
• Como aplicar na prática

📌 Produção, systemd e Cenários Reais

⚙️ systemd: a forma profissional de limitar CPU por processo

Na Parte 1 você viu como limitar CPU por processo usando cgroups diretamente. Isso funciona bem para testes, mas em produção o caminho correto é usar o systemd.

O systemd já integra cgroups internamente, o que significa que você não precisa gerenciar manualmente arquivos dentro de /sys/fs/cgroup.

Quando você usa systemd para limitar CPU por processo, você ganha:

• Persistência após reboot
• Controle automático de processos filhos
• Configuração centralizada
• Facilidade de manutenção

O uso de cgroups deve fazer parte de uma estratégia maior. Veja a abordagem completa de otimização de servidores Linux.

🧠 Como o systemd usa cgroups

Cada serviço gerenciado pelo systemd roda dentro de um cgroup próprio.

Ou seja, quando você aplica uma limitação, ela já afeta todo o grupo:

• Processo principal
• Workers
• Threads

Isso resolve um dos maiores problemas de quem tenta limitar CPU por processo manualmente: esquecer processos filhos.

⚙️ Aplicando limite de CPU com systemd

📌 Limite imediato (sem reiniciar serviço)

systemctl set-property php-fpm CPUQuota=50%

Esse comando já começa a limitar CPU por processo no serviço.

🔄 Tornar permanente

systemctl edit php-fpm

Adicione:

[Service]
CPUQuota=50%

📊 O que significa CPUQuota

• 100% = 1 CPU completa
• 200% = 2 CPUs
• 50% = metade de 1 CPU

👉 Em um servidor com múltiplos cores, isso continua válido por serviço.

⚙️ Outros parâmetros importantes

Ao trabalhar com limitar CPU por processo, você não deve usar apenas CPUQuota.

🔹 CPUWeight (prioridade relativa)

systemctl set-property nginx CPUWeight=200

• Valor padrão: 100
• Maior valor = maior prioridade

🔹 CPUQuotaPeriodSec

Define o período da quota:

systemctl set-property php-fpm CPUQuotaPeriodSec=100ms

🔹 AllowedCPUs (fixar cores)

systemctl set-property nginx AllowedCPUs=0,1

⚙️ Diferença crítica: processo vs serviço

Esse é um ponto onde muitos erram ao tentar limitar CPU por processo.

❌ Limitar apenas PID

Problema:

• Não pega processos filhos
• Não escala
• Difícil manutenção

✅ Limitar serviço completo

Com systemd:

• Todos os processos são controlados
• Mais previsível
• Mais seguro

🚀 Cenário real: WordPress com alto consumo

Vamos para um caso clássico.

🔥 Problema

• WordPress com tráfego alto
• Plugins pesados
• PHP-FPM consumindo 100% CPU

🎯 Solução

Aplicar limitar CPU por processo no PHP-FPM:

systemctl set-property php-fpm CPUQuota=60%

📊 Resultado esperado

• CPU não passa de 60%
• Outros serviços continuam funcionando
• Servidor não trava

🚀 Cenário real: múltiplos sites (DirectAdmin)

Ambientes com vários usuários são os mais críticos.

Sem controle, um cliente pode derrubar todos os outros.

🎯 Estratégia

Você pode aplicar limitar CPU por processo por serviço ou até criar isolamento por usuário.

📌 Exemplo básico

systemctl set-property httpd CPUQuota=70%

📌 Melhor abordagem (avançada)

Criar slices personalizados:

systemctl set-property user-1001.slice CPUQuota=30%

📊 Resultado

• Cada usuário tem limite
• Isolamento real
• Estabilidade geral

Controlar recursos é apenas um dos pilares da performance. Veja como melhorar a performance do servidor Linux.

⚙️ Aplicações críticas e limites ideais

🔹 PHP-FPM

• Ideal: 50% a 70%
• Motivo: evita picos

🔹 Nginx / Apache

• Ideal: 20% a 40%
• Motivo: geralmente não consome muito CPU

🔹 Banco de dados

Aqui entra cuidado.

⚠️ Banco de dados NÃO deve ser limitado agressivamente

Serviços como o MariaDB precisam de bursts de CPU.

Limitar demais pode causar:

• Queries lentas
• Deadlocks
• Timeouts

🧠 Estratégia avançada de balanceamento

Ao invés de apenas limitar CPU por processo, pense em balancear.

🔥 Exemplo profissional

• PHP-FPM → 60%
• Nginx → 30%
• Backup → 20%
• Banco → sem limite rígido

📊 Resultado

• CPU distribuída
• Sem gargalos
• Sistema previsível

⚠️ Erros críticos que você deve evitar

❌ Limitar CPU demais

Isso causa:

• Lentidão
• Timeout
• Experiência ruim

❌ Ignorar gargalo real

Às vezes o problema não é CPU:

• I/O alto
• Memória insuficiente
• Swap

❌ Não monitorar

Sempre use:

htop
top

❌ Aplicar em produção sem teste

Sempre valide antes.

📊 Monitoramento após aplicar limites

Depois de limitar CPU por processo, você precisa acompanhar.

🔍 Ferramentas recomendadas

• htop
• top
• uptime
• sar

📊 O que observar

• Load average
• Uso de CPU
• Tempo de resposta

🧠 Quando NÃO limitar CPU por processo

Apesar de útil, nem sempre é necessário.

❌ Servidor dedicado exclusivo

Se só há uma aplicação, limitar pode não ajudar.

❌ Aplicações de alto desempenho

Exemplo:

• processamento intensivo
• renderização
• análise de dados

🚀 Estratégia definitiva (nível avançado)

A melhor abordagem NÃO é apenas limitar CPU por processo.

É combinar:

🔥 Stack ideal

• cgroups / systemd
• ajuste de PHP-FPM
• cache (Redis, OPcache)
• CDN
• tuning de banco

💥 Resultado final

Ao aplicar corretamente:

• Seu servidor fica estável
• Evita picos de CPU
• Melhora performance
• Garante previsibilidade

📌Nível Expert, Isolamento e Otimização Profissional

🚀 Isolamento por usuário (alternativa ao CloudLinux)

Se você trabalha com hospedagem ou múltiplos projetos no mesmo servidor, apenas limitar CPU por processo por serviço pode não ser suficiente.

O problema real é:

👉 Um usuário pode consumir todos os recursos disponíveis.

Para resolver isso de forma profissional, você pode implementar isolamento por usuário usando cgroups.

🧠 Conceito de isolamento

A ideia é simples:

• Cada usuário recebe um limite de CPU
• Nenhum usuário pode ultrapassar esse limite
• O sistema permanece estável

Isso simula o comportamento de soluções comerciais como CloudLinux.

⚙️ Criando grupos por usuário

mkdir /sys/fs/cgroup/user1
mkdir /sys/fs/cgroup/user2

🎯 Aplicando limites

echo "30000 100000" > /sys/fs/cgroup/user1/cpu.max
echo "50000 100000" > /sys/fs/cgroup/user2/cpu.max

Aqui você está aplicando políticas diferentes ao limitar CPU por processo por usuário.

🔗 Associando processos automaticamente

Você pode usar systemd slices:

systemctl set-property user-1001.slice CPUQuota=30%

📊 Resultado

• Isolamento completo
• Nenhum usuário afeta outro
• Estabilidade em hospedagem compartilhada

⚙️ Controle avançado com slices do systemd

O systemd permite organizar recursos em “fatias” (slices).

🧠 Estrutura básica

• system.slice → serviços do sistema
• user.slice → usuários
• custom.slice → personalizado

🎯 Criando slice customizado

systemctl set-property myapp.slice CPUQuota=40%

Depois, associe serviços a esse slice.

📊 Vantagem

Você consegue limitar CPU por processo em grupos complexos de serviços.

🔥 Controle combinado: CPU + Memória + I/O

Limitar apenas CPU resolve parte do problema.

Mas servidores reais precisam de controle completo.

📌 Limitar memória

systemctl set-property php-fpm MemoryMax=2G

📌 Limitar I/O

systemctl set-property php-fpm IOWeight=200

🧠 Estratégia ideal

Combinar:

• CPUQuota
• MemoryMax
• IOWeight

Isso cria isolamento real.

🚀 Otimizando PHP-FPM junto com CPU

Se você apenas limitar CPU por processo, mas não ajustar PHP-FPM, ainda terá gargalos.

🔥 Configurações essenciais

No pool do PHP:

pm = dynamic
pm.max_children = 30
pm.max_requests = 500

📊 Por que isso importa?

• Evita excesso de processos
• Reduz consumo de CPU
• Mantém estabilidade

🧠 Regra prática

👉 CPU limitada + processos controlados = estabilidade real

⚙️ Ajustando o banco de dados corretamente

Ao trabalhar com limitar CPU por processo, o banco de dados merece atenção especial.

⚠️ Evite limitar agressivamente

O MariaDB precisa de CPU em picos.

📌 Melhor abordagem

• Não limitar CPU diretamente
• Ajustar queries
• Otimizar índices
• Configurar buffer pool

📊 Resultado

• Melhor performance
• Menos gargalos
• Menor latência

🔍 Diagnóstico antes de limitar CPU

Antes de sair aplicando limites, você deve identificar o problema.

📌 Comandos essenciais

top
htop

ps aux --sort=-%cpu | head

uptime

📊 O que analisar

• Quem consome CPU
• Frequência do problema
• Padrão de uso

🧠 Regra de ouro

👉 Nunca aplique limitar CPU por processo sem diagnóstico.

⚠️ Gargalos que NÃO são CPU

Muitos administradores cometem esse erro.

❌ I/O alto

Sintomas:

• CPU baixa
• Sistema lento

❌ Memória insuficiente

Sintomas:

• Swap alto
• Travamentos

❌ Rede

Sintomas:

• Latência alta
• Timeout

📊 Conclusão

Nem sempre você precisa limitar CPU por processo.

🚀 Estratégia de produção (nível empresa)

Aqui está um modelo profissional.

🎯 Setup completo

Web Server

CPUQuota=30%

PHP-FPM

CPUQuota=60%

Banco

Sem limite rígido

Backup

CPUQuota=20%

📊 Resultado

• Sistema equilibrado
• Sem gargalos críticos
• Alta estabilidade

🔥 Integração com containers (Docker)

Se você usa Docker, o conceito é o mesmo.

📌 Limitar CPU em container

docker run --cpus="1.5" nginx

🧠 Relação com cgroups

Docker usa cgroups internamente.

Ou seja, você já está aplicando limitar CPU por processo automaticamente.

⚙️ Kubernetes (nível enterprise)

Em Kubernetes:

resources:
  limits:
    cpu: "500m"

📊 Explicação

• 500m = 0.5 CPU
• Controle automático

🧠 Quando usar cada abordagem

🔹 cgroups manual

• Testes
• Laboratório

🔹 systemd

• Produção
• Servidores reais

🔹 Docker/Kubernetes

• Ambientes modernos
• Escalabilidade

📊 Checklist final (para produção)

Antes de aplicar limitar CPU por processo, valide:

✅ Identificou o problema

✅ Testou em ambiente seguro

✅ Definiu limites realistas

✅ Monitorou impacto

✅ Ajustou conforme necessário

📌 Conclusão final (artigo completo)

Ao longo deste guia completo, você aprendeu tudo sobre como limitar CPU por processo no Linux.

Desde o básico até o nível avançado, incluindo:

• cgroups v2
• systemd
• isolamento por usuário
• cenários reais
• estratégias profissionais

Para garantir estabilidade e desempenho, é essencial otimizar todo o ambiente. Consulte o guia de como otimizar servidores Linux.

💥 Resultado real

Ao aplicar corretamente:

• Seu servidor não trava
• Aplicações ficam isoladas
• CPU é usada de forma inteligente
• Performance melhora significativamente

FAQ

Veja Mais:

Performance de Servidores Linux: Guia Completo 2026
Swap Alto com RAM Livre: Por Que Isso Acontece e como Resolver
Servidor Lento: Como Identificar o Gargalo
I/O de disco servidor Linux: Como Resolver Gargalos
CPU 100% no Linux: O Que Verificar Primeiro no Servidor
Como Usar vmstat para Achar Gargalo no Linux em Minutos
Load Average no Linux: Como Interpretar Corretamente
Como Achar Gargalo com Iostat: Guia Definitivo e Prático
Iowait Alto: Causas Reais e Soluções
Guia Completo de Monitoramento Linux com vmstat, iostat e sar
Tuning de sysctl para Produção: Guia Definitivo de Performance Linux
OOM Killer e MySQL: Como Evitar que o Linux Mate seu Banco de Dados
Como Ajustar limits.conf no Linux: Guia para Alta Performance
Memory Leak Linux: Como Detectar e Corrigir
No space left on device com espaço livre? Como resolver (Guia Completo)
Como identificar processo que consome CPU no Linux (Guia Completo)
Upgrade de CPU ou Otimizar? Guia Completo
RAM Cheia no Linux: O Guia Definitivo para Resolver Travamentos em 2026
Buffers e Cache: Quando Deixam de Ajudar e Viram um Problema?
Out of Memory (OOM): Causas Reais, Diagnóstico e Como Resolver
Como evitar OOM Killer Linux em Produção: Guia Definitivo 2026
Gargalo no Linux: Como Identificar se o Problema é CPU ou RAM?
Disco Lento no Linux: Guia Completo para Identificar e Resolver
Latência de Disco no Linux Alta: Causas, Diagnóstico e Soluções