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/memoryExemplo 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
Localiza a restrição na hierarquia, mede o impacto na janela certa e comprova recuperação pela operação que o utilizador precisa.
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