- Порезанный
- 16 августа 2026 г. в 01:13 UTC
- Автор
- Kamo
- Обещать
- 66cfbc5
Контейнер работал с ограничением 1Gi, в то время как изображение запускает JVM. -XX:MaxRAMPercentage=70 -XX:+AlwaysPreTouch. Прочитайте живой процесс, то есть MaxHeapSize = 752877568 — 718Mi — и pre-touch означает, что резидентная память отслеживает Вместо того, чтобы отставать от него, он набирает обороты. Неплохая цена за эту услугу Меры ~240Mi: незавершенное метапространство, кэш кода, поток STOMP/NATS/Tomcat Стек и прямые буферы Минио. 718 плюс 240 больше 1024, поэтому капсула никогда не была размером с собственную кучу. Дойти до потолка, с которым он был настроен. Он не нуждался в утечке или всплеске Дорога должна была погибнуть, ее нужно было только использовать. Ядро OOMKilled его каждые несколько часов — 959 Ми анонимной памяти против 1024 Ми кэп, перезапуск 2 в 18 Часы — и каждое убийство забирало историю чата, реле веб-сокетов и каждую загрузку Полет с ним. 2Gi составляет тот же 70%-й сплит: 1434Mi из кучи плюс что ~240Mi составляет 1675Mi, Вместо дефицита 65 Ми вместо 370 Ми. Повышение лимита является Правый рычаг вместо того, чтобы понизить MaxRAMPercentage — 30% от 1Gi никогда не шли Применять Spring Boot в таком количестве подсистем. Запросы идут 512Mi→1Gi, так что планировщику говорят правду о полу. Уже применяется вживую с кубектльным набором ресурсов; это манифест ловли Поэтому следующий CI не возвращает его обратно.