Java использует намного больше памяти, чем размер кучи (или правильно определяет размер Docker memory limit)
Переведено автоматически
Ответ 1
Виртуальная память, используемая процессом Java, выходит далеко за рамки просто кучи Java. Вы знаете, JVM включает в себя множество подсистем: сборщик мусора, загрузка классов, JIT-компиляторы и т.д., И всем этим подсистемам требуется определенный объем оперативной памяти для функционирования.
JVM - не единственный потребитель оперативной памяти. Собственные библиотеки (включая стандартную библиотеку классов Java) также могут выделять собственную память. И это даже не будет видно для отслеживания встроенной памяти. Само Java-приложение также может использовать память вне кучи с помощью прямых байт-буферов.
Итак, что же занимает память в процессе Java?
Части JVM (в основном показаны при отслеживании встроенной памяти)
1. Java Heap
Самая очевидная часть. Здесь находятся объекты Java. Куча занимает до -Xmx объема памяти.
2. Сборщик мусора
Структурам и алгоритмам GC требуется дополнительная память для управления кучей. Этими структурами являются Mark Bitmap, Mark Stack (для обхода графа объектов), запоминаемые наборы (для записи межрегиональных ссылок) и другие. Некоторые из них настраиваются напрямую, например, -XX:MarkStackSizeMax, другие зависят от расположения кучи, например, чем больше области G1 (-XX:G1HeapRegionSize), тем меньше запоминаемые наборы.
Накладные расходы на GC-память различаются в зависимости от алгоритмов GC. -XX:+UseSerialGC и -XX:+UseShenandoahGC имеют наименьшие накладные расходы. G1 или CMS могут легко использовать около 10% от общего размера кучи.
3. Кэш кода
Содержит динамически генерируемый код: JIT-скомпилированные методы, интерпретатор и заглушки времени выполнения. Его размер ограничен -XX:ReservedCodeCacheSize (240 М по умолчанию). Отключите -XX:-TieredCompilation, чтобы уменьшить объем скомпилированного кода и, следовательно, использование кэша кода.
4. Компилятор
Самому JIT-компилятору также требуется память для выполнения своей работы. Это можно снова уменьшить, отключив многоуровневую компиляцию или уменьшив количество потоков компилятора: -XX:CICompilerCount.
5. Загрузка класса
Метаданные класса (байт-коды методов, символы, пулы констант, аннотации и т.д.) Хранятся вне кучи, называемой метапространством. Чем больше классов загружено - тем больше метапространства используется. Общее использование может быть ограничено -XX:MaxMetaspaceSize (неограниченно по умолчанию) и -XX:CompressedClassSpaceSize (1G по умолчанию).
6. Таблицы символов
Две основные хэш-таблицы JVM: таблица символов содержит имена, подписи, идентификаторы и т.д., А таблица строк содержит ссылки на интернированные строки. Если отслеживание встроенной памяти указывает на значительное использование памяти строковой таблицей, это, вероятно, означает, что приложение выполняет чрезмерные вызовы String.intern.
7. Потоки
Стеки потоков также отвечают за потребление оперативной памяти. Размер стека контролируется -Xss. По умолчанию 1 м на поток, но, к счастью, все не так плохо. ОС распределяет страницы памяти лениво, т. Е. При первом использовании, поэтому фактическое использование памяти будет намного ниже (обычно 80-200 КБ на стек потоков). Я написал скрипт, чтобы оценить, какая часть RSS принадлежит стекам потоков Java.
Существуют и другие части JVM, которые выделяют собственную память, но обычно они не играют большой роли в общем потреблении памяти.
Прямые буферы
Приложение может явно запросить память вне кучи, вызвав ByteBuffer.allocateDirect. Ограничение вне кучи по умолчанию равно -Xmx, но его можно переопределить с помощью -XX:MaxDirectMemorySize. Прямые байт-буферы включены в Other раздел вывода NMT (или Internal до JDK 11).
Объем используемой напрямую памяти виден через JMX, например, в JConsole или Java Mission Control:
Помимо прямых байт-буферов могут быть MappedByteBuffers - файлы, отображенные в виртуальную память процесса. NMT их не отслеживает, однако MappedByteBuffers также могут занимать физическую память. И нет простого способа ограничить объем, который они могут занимать. Вы можете просто увидеть фактическое использование, просмотрев карту памяти процесса: pmap -x <pid>
Address Kbytes RSS Dirty Mode Mapping
...
00007f2b3e557000 39592 32956 0 r--s- some-file-17405-Index.db
00007f2b40c01000 39600 33092 0 r--s- some-file-17404-Index.db
^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
Собственные библиотеки
Код JNI, загруженный System.loadLibrary, может выделять столько памяти вне кучи, сколько захочет, без контроля со стороны JVM. Это также касается стандартной библиотеки классов Java. В частности, незакрытые ресурсы Java могут стать источником утечки встроенной памяти. Типичными примерами являются ZipInputStream или DirectoryStream.
Агенты JVMTI, в частности, jdwp debugging agent - также могут вызывать чрезмерное потребление памяти.
Этот ответ описывает, как профилировать выделение встроенной памяти с помощью async-profiler.
Проблемы с распределителем
Процесс обычно запрашивает собственную память либо напрямую из ОС (с помощью mmap системного вызова), либо с помощью malloc стандартного распределителя libc. В свою очередь, malloc запрашивает большие куски памяти у операционной системы с помощью mmap, а затем управляет этими кусками в соответствии со своим собственным алгоритмом распределения. Проблема в том, что этот алгоритм может привести к фрагментации и чрезмерному использованию виртуальной памяти.
jemalloc альтернативный распределитель часто оказывается умнее обычного libc malloc, поэтому переключение на jemalloc может привести к уменьшению занимаемой площади бесплатно.
Заключение
Не существует гарантированного способа оценить полное использование памяти Java-процессом, поскольку необходимо учитывать слишком много факторов.
Total memory = Heap + Code Cache + Metaspace + Symbol tables +
Other JVM structures + Thread stacks +
Direct buffers + Mapped files +
Native Libraries + Malloc overhead + ...
Можно уменьшить или ограничить определенные области памяти (например, кэш кода) с помощью флагов JVM, но многие другие вообще не контролируются JVM.
Одним из возможных подходов к установке ограничений Docker было бы наблюдение за фактическим использованием памяти в "нормальном" состоянии процесса. Существуют инструменты и методы для исследования проблем с потреблением памяти Java: отслеживание встроенной памяти, pmap, jemalloc, async-profiler.
Обновить
Вот запись моей презентации Объем памяти Java-процесса.
В этом видео я обсуждаю, что может потреблять память в процессе Java, как отслеживать и ограничивать размер определенных областей памяти и как профилировать утечки встроенной памяти в приложении Java.
Ответ 2
Ответ 3
Ответ 4