- Порезанный
- 25 августа 2026 г. в 19:39 UTC
- Автор
- Kamo
- Обещать
- c22edbb
Две ошибки, одна моя. MINE FIRST: ворот «узел-тест» добавлен со сценарием автоматического подключения в DIRECTORY, и узел бегуна разрешает голый каталог в качестве модуля для Выполнение — MODULE NOT FOUND, выход 1, развертывание не удалось. После этого обе стороны отступают. Условно-перезапускное и канарейное ложно-тревожное исправление) поэтому никогда не отгружается; Пробеги 9150 и 9152 потерпели неудачу и кластер остался на 3342ccd. Наименование испытания Файл исправляет это. Проверено точной командой CI, от корня repo. «Ошибка произошла» из ниоткуда в 19:30 был OOMKill 137), ни утечки, ни перезапуска развертывания. «jcmd VM.flags» в прямом эфире MaxHeapSize = 32210157568 — потолок на 32 ГБ внутри 2 ГБ контейнер. Это Java 8 на хосте cgroup v2: его обнаружение контейнеров никогда читает /sys/fs/cgroup/memory.max (предел IS виден там, 2147483648), так что Вместо этого он был размером с 128 ГБ хоста. Eden вырос до ~ 1,0 ГБ и старого поколения ~0,93 ГБ, в то время как живой набор составлял ~23 МБ; без давления для сбора, RSS 821 МиБ -> 1963 МиБ более четырех часов, и ядро убило его в предел. Прометей показывает эту кривую, и она началась раньше канарейки. Существовала, поэтому канарейка не причастна. Xmx768m полностью устраняет зависимость от обнаружения контейнеров. MALLOC ARENA MAX и ActiveProcessorCount останавливают glibc и GC от калибровки себя против Узел 48 процессоров. Повышение лимита снова было неправильным шагом само по себе: 1Gi->2Gi Они уже были опробованы и изменили только то, сколько времени это заняло. Добавлены оповещения как по подходу (>85% лимита), так и по событию (OOMKilled). потому что шлюз не деградирует, когда у него заканчивается память — он погибает, И каждый открытый рабочий стол идет вместе с ним.