- Navios
- 25 de agosto de 2026 às 19:39 UTC
- Autor
- Kamo
- Enviar
- c22edbb
Dois defeitos, um deles é meu. MINHA PRIMEIRA: o portão `node --test` adicionado com o script de reconexão automática apontado em uma DIRECÇÃO, e o nó do corredor resolve um diretório nu como um módulo para execute — MODULE NOT FOUND, saída 1, implantação falhou. Ambos empurram após ele (o Consequentemente, a correção condicional de reinício e a correção do falso alarme canário) nunca foram enviadas; runs 9150 e 9152 falharam e o cluster permaneceu em 3342ccd. Nomeação do teste O ficheiro conserta-o. Verificado com o comando exato que o CI executa, a partir do repo root. OOM: "um erro ocorreu" do nada às 19:30 foi um OOMKill (saída 137), não uma fuga e não o reinício da implantação. 'jcmd VM.flags' na cápsula viva comunicado MaxHeapSize=32210157568 — um teto de 32 GB de heap dentro de um 2 GiB recipiente. Este é o Java 8 numa máquina cgroup v2: a sua detecção de contentores nunca lê /sys/fs/cgroup/memory.max (o limite é visível lá, 2147483648), então ele dimensionou-se contra os 128 GB da máquina. Éden cresceu para ~1.0 GB e geração antiga para ~0.93 GB enquanto o conjunto ao vivo foi ~23 MB; sem pressão para coletar, RSS escalou 821 MiB -> 1963 MiB mais de quatro horas e o kernel matou-o no limite. Prometeu mostra essa curva exatamente, e começou ANTES do canário O canário não está implicado. -Xmx768m remove inteiramente a dependência da detecção do recipiente. MALLOC ARENA MAX e ActiveProcessorCount parar glibc e o GC de se dimensionar contra o O nó tem 48 CPUs. Aumentar o limite novamente foi o movimento errado por conta própria: 1Gi->2Gi já tinha sido tentado e só mudou quanto tempo levou. Alertas adicionados tanto para a abordagem (>85% do limite) como para o evento (OOMKilled), porque a porta de entrada não se degrada quando fica sem memória — ela é morta, e cada desktop aberto vai com ele.