G C и поведение памяти для Java и PHP приложения? - PullRequest
0 голосов
/ 28 января 2020

Этот вопрос касается поведения сборки мусора, когда запросу требуется больше памяти, чем выделено для Pod. Если G C не может освободить память, он продолжит непрерывно работать G C или выбрасывается из памяти.

Один модуль содержит приложение на основе java, а другой - на основе PHP. В случае java значение xmx совпадает с заданным для pod limit.

1 Ответ

1 голос
/ 28 января 2020

Я могу говорить только о Java G C. (Поведение PHP G C будет другим.)

Если G C не сможет освободить память, продолжит ли он непрерывно запускать G C через регулярный интервал или выбросить из памяти.

Это зависит от параметров JVM.

JVM начинается с начального размера кучи и расширяет его по мере необходимости. Тем не менее, он будет только расширять кучу до фиксированного максимального размера. Этот максимальный размер определяется, когда JVM запускается либо с помощью опции (-Xmx), либо правил размера кучи по умолчанию. Его нельзя изменить после запуска.

Поскольку используемое пространство кучи приближается к пределу, G C может появляться все чаще и чаще. Поведение по умолчанию в современной JVM - это мониторинг% времени, затраченного на сборку мусора. Если он превышает (настраиваемый) порог, вы получите OOME с сообщением о превышении порогового значения G C. Это может произойти, даже если есть достаточно места, чтобы «хромать» немного дольше.

Вы можете отключить G C Ограничение накладных расходов, но это нежелательно.

JVM также сгенерирует OOME, если у нее просто не будет достаточно места в куче после выполнения полной сборки мусора.

Наконец, JVM сгенерирует OOME, если попытается увеличить кучу и ОС отказывается предоставить ей запрошенную память. Это может произойти из-за того, что:

  • в операционной системе исчерпано ОЗУ
  • в операционной системе исчерпано пространство подкачки
  • процесс превысил ulimit, или
  • группа процессов (контейнер) превысила ограничение контейнера.

JVM знает лишь незначительно о доступной памяти в своей среде. На голой железной ОС или виртуальной машине под гипервизором размер кучи по умолчанию зависит от объема оперативной памяти. На голой металлической ОС это физическая память. На виртуальной машине это будет ... то, что гостевая ОС воспринимает как физическую память.

В Kubernetes память, доступная для приложения, вероятно, будет дополнительно ограничена cgroups или подобными. Я понимаю, что последние версии Java имеют настройки, которые делают их более подходящими для работы в контейнерах. Я думаю, это означает, что они могут использовать ограничения памяти cgroup, а не физический объем памяти при расчете размера кучи по умолчанию.

...