Диаграммы по управлению памятью в Java процессе

[Kopilov]

Что кроме кучи есть стек, нативные буферы и прочее — для кого-то, может, и окажется новостью (или полезным напоминанием).
Но причём тут Docker? Что изменится, если применить эту диаграмму к хостовой системе с ограниченными ресурсами?

[Manitou]

Вот тут поясняется, в чем проблема и «что изменится»: developers.redhat.com/blog/2017/03/14/java-inside-docker TL;DR: JVM «видит» объём памяти хостовой машины и не обращает внимания на limit указанный контейнеру, получаются интересные эффекты. Этим отличается запуск JVM на машине с ограниченными ресурсами и в контейнере с «ограниченными ресурсами».

[sparhawk]

Закопайте назад эту статью! Эта проблема уже давно пофикшена (с 8u131 экспериментально и с 8u191 окончательно). Даже в приведенной вами статье добавлена сноска про фикс.
Данная статья вообще не про это, а вообще непонятно про что про типы памяти JVM, и что нативный не-Java код (сюрприз! сюрприз!) не обращает внимания ни на Xmx с Xms и прочими параметры памяти, назначенные JVM, ни вообще на количество доступной памяти, а тем более cgroups, если его разработчик отдельно об этом не подумал.

[AlekseySamoylov]

Спасибо за комментарий. Заголовок и содержание поправил, чтобы не вносить путаницу с Docker'ом, и показать, что статья — справочная диаграмма использования памяти Java процесса.

[AlekseySamoylov]

Спасибо за комментарий. Согласен, информация про Docker полезной нагрузки статье не добавляет и заголовок вводит в заблуждение. Исправил. OS также имеет возможность убить процесс, из-за потребления памяти и результат будет аналогичен моей истории с Docker.

[vr_17]

нижняя диаграмма более-менее читабельна в масштабе страницы 150%

[AlekseySamoylov]

Увеличил шрифты, загрузил картинку большего размера, но Хабр не дает возможность увеличить ее в интерфейсе. Рекомендую загрузить эту картинку и увеличивать вручную. Она достаточно хорошего качества.

[shishmakov]

Почему Direct ByteBuffers не часть «memory footprint» Java-процесса?