← Administração Linux para operações
09 / 12 · 45 MIN

Isolar recursos e comprovar prontidão em Linux

Relaciona limites de cgroups, pressão de recursos e semântica de arranque com decisões de recuperação de serviços.

O serviço existe, mas está pronto?

Um arranque tem várias fronteiras: criação do processo, inicialização da aplicação, disponibilidade de dependências e aceitação de uma operação real. Escreve qual fronteira o consumidor precisa de observar. Numa API fictícia, a porta pode abrir antes de o catálogo de instrumentos estar carregado. Type=simple não expressa essa condição funcional. Type=notify só ajuda se a aplicação implementar corretamente a notificação. After= ordena jobs, mas não inicia por si só uma dependência nem testa uma consulta SQL. Desenha a ativação, a ordem e a verificação funcional como decisões distintas, com um ensaio de falha de dependência.

Quota, peso e capacidade disponível

Usa a pergunta operacional para escolher o controlo. CPUQuota define um teto de tempo relativo a uma CPU; CPUWeight influencia a partilha entre irmãos sob contenção. No exercício, um batch tem CPUQuota=150% num host com oito CPUs: o teto equivale a 1,5 CPUs, não a doze. Isso também não garante que consiga usar toda essa capacidade. Antes de pedir hardware, observa a configuração efetiva, diferenças de throttling durante a execução e progresso do batch. Uma alteração aprovada deve medir também o impacto nos serviços vizinhos e preservar a possibilidade de reversão.

Memória: localizar a restrição

O host e a unit têm orçamentos diferentes. Num exercício com 12 GiB livres no host e memory.max de 2 GiB na folha, a memória global não elimina o limite local. Observa também os antepassados: um pai partilhado pode restringir a carga antes de esta atingir o seu próprio teto. MemoryHigh pode associar-se a reclaim e atrasos; MemoryMax pode levar a OOM quando a utilização não consegue ser contida. Regista diferenças de eventos, período e identidade do cgroup. Um OOM confirma uma condição, mas não distingue sozinho fuga, pico legítimo ou dimensionamento inadequado.

Medir bloqueio e evitar falsos culpados

PSI acrescenta uma perspetiva temporal: mostra o tempo durante o qual tarefas perdem progresso por pressão de recursos. some e full descrevem condições diferentes; nenhum deles é uma percentagem de memória ocupada. Compara a mesma janela com latência, volume de trabalho e contadores da hierarquia. Em memory.events, um aumento num pai pode vir de um descendente; memory.events.local ajuda a separar o âmbito. Não somes médias sobrepostas nem uses um contador cumulativo como número de falhas no último minuto. Para falhas de criação de threads, compara também TasksCurrent e TasksMax, que incluem tarefas e não apenas processos visíveis numa listagem resumida.

Recuperar sem multiplicar efeitos

Antes de repetir um batch, identifica a última fronteira confirmada. Se uma instrução foi aceite externamente e o checkpoint local falhou, um restart pode duplicar efeitos. Usa identidade de operação, consulta de estado e repetição limitada conforme o contrato real. Start-limit-hit descreve uma proteção de arranque; limpar esse estado não corrige a configuração inicial. Preserva a evidência, trata a causa observada e valida a retoma. Num exercício autorizado, produz uma ficha com hipótese, comando de leitura, resultado esperado, resultado contrário à hipótese, mitigação, autoridade e critério de aceitação. Nenhum valor de limite deste módulo é uma recomendação universal de produção.

systemctl show funds-api.service -p Type -p MainPID -p ControlGroup -p CPUQuotaPerSecUSec -p MemoryHigh -p MemoryMax -p TasksCurrent -p TasksMax
systemctl cat funds-api.service
journalctl -u funds-api.service --since "2026-10-01 06:00:00 UTC" --until "2026-10-01 06:15:00 UTC" --no-pager
cat /proc/pressure/memory
NA PRÁTICA

Exemplo fictício: a API deixa de responder, oom_kill local aumenta de 0 para 1 e o kernel identifica o cgroup limitado a 2 GiB. Reduzir a concorrência autorizada recupera o serviço. Regista a mitigação e investiga o perfil de memória; não declares uma fuga corrigida nem alteres limites dos restantes serviços.

Armadilhas comuns

Confundir peso com quota, RAM livre com ausência de limite, active com prontidão, reset-failed com reparação ou restart com entrega única.

Tópicos relacionados: Interpretar serviços e logs com systemd · Distinguir espaço, inodes e montagem · Interpretar CPU, memória e espera por I/O · Manutenção e recuperação demonstrada

Leva esta ideia contigo

Localiza a restrição na hierarquia, mede o impacto na janela certa e comprova recuperação pela operação que o utilizador precisa.

Criar conta

Referência: systemd.resource-control(5) · DR Linux 2026.4; networking and Bash manuals reviewed 2026-10-01; cgroup v2 and upstream systemd manuals reviewed 2026-10-01; RHEL 10 examples; Linux man-pages 6.19; OpenSSL 3.5

Linux® é uma marca registada de Linus Torvalds. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Linus Torvalds. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.