Какие бывают типы OutOfMemoryError или из каких частей состоит память java процесса
Если вы словили OutOfMemoryError, то это вовсе не значит, что ваше приложение создает много объектов, которые не могут почиститься сборщиком мусора и заполняют всю память, выделенную вами с помощью параметра -Xmx. Я, как минимум, могу придумать два других случая, когда вы можете увидеть эту ошибку. Дело в том, что память java процесса не ограничивается областью -Xmx, где ваше приложение программно создает объекты.
Область памяти, занимаемая java процессом, состоит из нескольких частей. Тип OutOfMemoryError зависит от того, в какой из них не хватило места.
1. java.lang.OutOfMemoryError: Java heap space
Не хватает место в куче, а именно, в области памяти в которую помещаются объекты, создаваемые программно в вашем приложении. Размер задается параметрами -Xms и -Xmx. Если вы пытаетесь создать объект, а места в куче не осталось, то получаете эту ошибку. Обычно проблема кроется в утечке памяти, коих бывает великое множество, и интернет просто пестрит статьями на эту тему.
2. java.lang.OutOfMemoryError: PermGen space
Данная ошибка возникает при нехватке места в Permanent области, размер которой задается параметрами -XX:PermSize и -XX:MaxPermSize. Что там лежит и как бороться с OutOfMemoryError возникающей там, я уже описал подробнейшим образом тут.
3. java.lang.OutOfMemoryError: GC overhead limit exceeded
Данная ошибка может возникнуть как при переполнении первой, так и второй областей. Связана она с тем, что памяти осталось мало и GC постоянно работает, пытаясь высвободить немного места. Данную ошибку можно отключить с помощью параметра -XX:-UseGCOverheadLimit, но, конечно же, её надо не отключать, а либо решать проблему утечки памяти, либо выделять больше объема, либо менять настройки GC.
4. java.lang.OutOfMemoryError: unable to create new native thread
Впервые я столкнулся с данной ошибкой несколько лет назад, когда занимался нагрузочным тестированием и пытался выяснить максимальное количество пользователей, которые могут работать с нашим веб-приложением. Я использовал специальную тулзу, которая позволяла логинить пользователей и эмулировать их стандартные действия. На определенном количестве клиентов, я начал получать OutOfMemoryError. Не особо вчитываясь в текст сообщения и думая, что мне не хватает памяти на создание сессии пользователя и других необходимых объектов, я увеличил размер кучи приложения (-Xmx). Каково же было мое удивление, когда после этого количество пользователей одновременно работающих с системой только уменьшилось. Давайте подробно разберемся как же такое получилось.
На самом деле это очень просто воспроизвести на windows на 32-битной машине, так как там процессу выделяется не больше 2Гб.
Допустим у вас есть приложение с большим количеством одновременно работающих пользователей, которое запускается с параметрами -Xmx1024M -XX:MaxPermSize=256M -Xss512K. Если всего процессу доступно 2G, то остается свободным еще коло 768M. Именно в данном остатке памяти и создаются стеки потоков. Таким образом, примерно вы можете создать не больше 768*(1024/512)=1536 (у меня при таких параметрах получилось создать 1316) нитей (см. рисунок в начале статьи), после чего вы получите OutOfMemoryError. Если вы увеличиваете -Xmx, то количество потоков, которые вы можете создать соответственно уменьшается. Вариант с уменьшением -Xss, для возможности создания большего количества потоков, не всегда выход, так как, возможно, у вас существуют в системе потоки требующие довольно больших стеков. Например, поток инициализации или какие-нибудь фоновые задачи. Но все же выход есть. Оказывается при программном создании потока, можно указать размер стека: Thread(ThreadGroup group, Runnable target, String name,long stackSize). Таким образом вы можете выставить -Xss довольно маленьким, а действия требующие больших стеков, выполнять в отдельных потоках, созданных с помощью упомянутого выше конструктора.
Более подробно, что же лежит в стеке потока, и куда уходит эта память, можно прочитать тут.
Конечно, вам может показаться данная проблема слегка надуманной, так как большинство серверов нынче крутиться на 64-битной архитектуре, но все же считаю данный пример весьма полезным, так как он помогает разобраться из каких частей состоит память java-процесса.
3.2 Understand the OutOfMemoryError Exception
One common indication of a memory leak is the java.lang.OutOfMemoryError exception. Usually, this error is thrown when there is insufficient space to allocate an object in the Java heap. In this case, The garbage collector cannot make space available to accommodate a new object, and the heap cannot be expanded further. Also, this error may be thrown when there is insufficient native memory to support the loading of a Java class. In a rare instance, a java.lang.OutOfMemoryError may be thrown when an excessive amount of time is being spent doing garbage collection and little memory is being freed.
When a java.lang.OutOfMemoryError exception is thrown, a stack trace is also printed.
The java.lang.OutOfMemoryError exception can also be thrown by native library code when a native allocation cannot be satisfied (for example, if swap space is low).
An early step to diagnose an OutOfMemoryError exception is to determine the cause of the exception. Was it thrown because the Java heap is full, or because the native heap is full? To help you find the cause, the text of the exception includes a detail message at the end, as shown in the following exceptions.
In other cases, and in particular for a long-lived application, the message might be an indication that the application is unintentionally holding references to objects, and this prevents the objects from being garbage collected. This is the Java language equivalent of a memory leak. Note: The APIs that are called by an application could also be unintentionally holding object references.
One other potential source of this error arises with applications that make excessive use of finalizers. If a class has a finalize method, then objects of that type do not have their space reclaimed at garbage collection time. Instead, after garbage collection, the objects are queued for finalization, which occurs at a later time. In the Oracle Sun implementation, finalizers are executed by a daemon thread that services the finalization queue. If the finalizer thread cannot keep up, with the finalization queue, then the Java heap could fill up and this type of OutOfMemoryError exception would be thrown. One scenario that can cause this situation is when an application creates high-priority threads that cause the finalization queue to increase at a rate that is faster than the rate at which the finalizer thread is servicing that queue.
If this type of the OutOfMemoryError exception is thrown, you might need to use troubleshooting utilities on the operating system to diagnose the issue further. For more information about tools available for various operating systems, see Native Operating System Tools.
CompressedClassSpaceSize of 4294967296 is invalid; must be between 1048576 and 3221225472.
Note: There is more than one kind of class metadata — klass metadata and other metadata. Only klass metadata is stored in the space bounded by CompressedClassSpaceSize . The other metadata is stored in Metaspace .
Русские Блоги
Итак, обычно есть две причины этой аномалии:
1. В программе есть бесконечный цикл.
2. Программа занимает слишком много памяти, что превышает максимальное значение, установленное кучей JVM.
В первом случае вам необходимо самостоятельно проверить программный код, поэтому я не буду здесь говорить больше.
Во втором случае мы вручную расширяем настройки параметров кучи JVM. Настройка кучи JVM относится к настройке пространства памяти, которое JVM может выделить и использовать во время выполнения программы java. Когда JVM запускается, куча JVM автоматически устанавливает значение размера кучи. Обычно значение по умолчанию для начального пространства (например, -Xms) составляет 1/64 физической памяти, а максимальное пространство составляет 1/4 физической памяти. Его можно установить с помощью таких параметров, как -Xmn -Xms -Xmx, предоставляемых JVM. Вот объяснение значения каждого параметра:
-Xms: начальное значение
-Xmx: максимум
-Xmn: минимальное значение
Размер кучи не должен быть слишком маленьким или слишком большим. Если параметр слишком мал, скорость отклика программы будет ниже, потому что сборщик мусора занимает больше времени, а приложение выделяет меньше времени на выполнение. Слишком большой размер также приведет к потере места и повлияет на нормальную работу других программ. Размер кучи не должен превышать 80% доступной физической памяти. Рекомендуется установить одинаковые параметры -Xms и -Xmx, а -Xmn составляет 1/4 значения -Xmx.
Основные методы настройки следующие:
1. Этот параметр добавляется при выполнении файла класса JAVA, где className — это имя класса, который необходимо выполнить. (Включая имя пакета) Например: java -Xms32m -Xmx800m className Это не только решает проблему, но и скорость выполнения намного выше, чем когда она не установлена. Если это тест разработки, вы также можете установить его прямо в eclipse. Введите -Xms32m -Xmx800m в аргументы виртуальной машины в Eclipse -> run -arguments.
2. Вы можете изменить системные переменные среды в Windows и добавить JAVA_OPTS = -Xms64m -Xmx512m.
3. Если вы используете tomcat под окнами, вы можете добавить в C: tomcat5.5.9 bin catalina.bat (конкретный путь зависит от местоположения вашего tomcat): установить JAVA_OPTS = -Xms64m -Xmx256m (размер зависит от вашей собственной памяти) Местоположение: rem Угадайте CATALINA_HOME, если не определено Добавьте соответствующее в этой строке.
4. Если это система Linux, добавьте набор JAVA_OPTS = ’- Xms64 -Xmx512’ перед /bin/catalina.sh
Поскольку программе необходимо прочитать около 10 Вт строк записей из данных для обработки, возникает ошибка типа java.lang.OutOfMemoryError: пространство кучи Java появляется при чтении 9 Вт.
Проверка в Интернете может быть причиной того, что параметр стека JAVA слишком мал.
Согласно ответам в Интернете, существует примерно два решения:
1. Задайте переменные среды.
set JAVA_OPTS= -Xms32m -Xmx512m
можно изменить в соответствии с объемом памяти вашего компьютера, но моя проверка этого метода не решила проблему. Это может быть где еще нужно установить.
2、java -Xms32m -Xmx800m className
— добавить этот параметр при выполнении файла класса JAVA, где className — это фактическое имя класса, который должен быть выполнен. (Включая название пакета)
Это решает проблему. И скорость выполнения намного выше, чем без настройки.
Если вы можете использовать Eclispe при тестировании, вам необходимо ввести параметр -Xms32m -Xmx800m в аргументы виртуальной машины в Eclipse -> run -arguments.
java.lang.OutOfMemoryError: Java heap space
Исключение возникает при использовании программы Java для запроса большого количества данных из базы данных:
java.lang.OutOfMemoryError: Java heap space
В JVM, если 98% времени используется для сборки мусора, а доступный размер кучи меньше 2%, будет выдано это сообщение об исключении.
Настройка кучи JVM относится к настройке пространства памяти, которое JVM может выделить и использовать во время выполнения программы java.
JVM автоматически установит значение размера кучи при запуске.Его начальное пространство (-Xms) составляет 1/64 физической памяти, а максимальное пространство (-Xmx) — 1/4 физической памяти. Его можно установить с помощью таких параметров, как -Xmn -Xms -Xmx, предоставляемых JVM.
Например: java -jar -Xmn16m -Xms64m -Xmx128m MyApp.jar
Если размер кучи установлен слишком маленьким, в дополнение к этим аномальным сообщениям вы обнаружите, что скорость отклика программы снижается. Сборщик мусора занимает больше времени, а приложение выделяет меньше времени на выполнение.
Размер кучи не должен превышать 80% доступной физической памяти.Обычно для параметров -Xms и -Xmx должны быть установлены одинаковые значения, а -Xmn составляет 1/4 значения -Xmx.
Параметры размера кучи -Xms -Xmn не должны превышать размер физической памяти. В противном случае появится сообщение «Ошибка при инициализации виртуальной машины. Не удалось зарезервировать достаточно места для кучи объектов».
==========================================================
После ночи напряженной работы я наконец завершил программу замены файлов для указанной строки, но поскольку я хочу заменить слишком много файлов html для общесайтовой программы, поэтому затмение всегда заканчивается в каталоге После сообщения об исключении java.lang.OutOfMemoryError: пространство кучи Java произошел сбой.
Я подумал, что слишком поздно перерабатывать из-за частых операций, поэтому я добавил Thread.sleep (1000) после каждого цикла и обнаружил, что он умрет в этом каталоге, поэтому я изменил 1000 на 5000 или умер там. Я думаю, что это может быть не так просто перерабатывать, возможно, JVM Sun просто не выпускает для этой ситуации.
Затем я добавил -Xmx256M к параметру запуска, на этот раз все было нормально.
Подумав об этом, я до сих пор мало что знаю о принципах сборки мусора, я проверил это в Интернете и нашел несколько хороших статей.
Также существуют: Управление кучей Java — сборка мусора. Следует отметить следующие моменты, которые могут использоваться в качестве рекомендаций при написании программ:
(1) Не пытайтесь предполагать время, когда происходит сборка мусора, причем все это неизвестно. Например, временный объект в методе становится бесполезным после вызова метода, и его память может быть освобождена в это время.
(2) Java предоставляет несколько классов, которые занимаются сборкой мусора, и предоставляет способ принудительного вызова функции сборки мусора System.gc (), но это также ненадежный метод. Java не гарантирует, что сборка мусора будет запускаться каждый раз при вызове этого метода. Она просто отправляет такой запрос в JVM. Неизвестно, выполняется ли сборка мусора на самом деле.
(3) Выберите подходящий вам сборщик мусора. Вообще говоря, если система не предъявляет особых требований к производительности, вы можете использовать параметры JVM по умолчанию. В противном случае вы можете рассмотреть возможность использования целевых сборщиков мусора.Например, инкрементные сборщики больше подходят для систем с высокими требованиями к работе в реальном времени. Система имеет более высокую конфигурацию и больше простаивающих ресурсов, вы можете рассмотреть возможность использования параллельного сборщика меток / разверток.
(4) Ключевая и сложная проблема — это утечки памяти. Хорошие навыки программирования и строгое отношение к программированию всегда являются самыми важными. Не позволяйте небольшой собственной ошибке вызвать большую дыру в памяти.
(5) Освободите ссылки на бесполезные объекты как можно скорее.
Когда большинство программистов используют временные переменные, они автоматически устанавливают для ссылочной переменной значение null после выхода из активной области (области), что означает, что сборщик мусора будет собирать объект. Вы должны обратить внимание на то, отслеживается ли объект, на который указывает ссылка, если да, удалите прослушиватель, а затем назначьте нулевое значение.
Другими словами, лучше контролировать операции частого обращения к памяти и освобождения памяти самостоятельно, но метод System.gc () может быть неприменим. Лучше использовать finalize для принудительного выполнения или написать свой собственный метод finalize.
Я обнаружил ошибку TOMCAT: java.lang.OutOfMemoryError: пространство кучи Java, поэтому я проверил информацию и нашел решение:
If Java runs out of memory, the following error occurs:
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
Java heap size can be increased as follows:
java -Xms -Xmx
Defaults are:
java -Xms32m -Xmx128m
Если вы используете выигрыш
/tomcat/bin/catalina.bat плюс следующая команда:
set JAVA_OPTS=-Xms32m -Xmx256m
Если вы используете unix / linux
/tomcat/bin/catalina.sh плюс следующая команда:
JAVA_OPTS=»-Xms32m -Xmx256m»
инструмент просмотра и анализа памяти jvm
В отрасли существует множество мощных инструментов для профилей Java, таких как Jporfiler и yourkit. Я не хочу говорить об этих платных вещах. Я хочу сказать, что сама java обеспечивает большой мониторинг памяти. Маленькие инструменты, перечисленные ниже инструменты — лишь небольшая часть. Все еще довольно интересно внимательно изучить инструменты jdk 🙂
1: вывод журнала gc
-verbose: gc и -XX: + PrintTenuringDistribution и т. д.
Код коллекции HTML-кода
Usage:
jmap -histo (to connect to running process and print histogram of java object heap
jmap -dump: (to connect to running process and dump java heap)
dump-options: format=b binary default file=
dump heap to
Example: jmap -dump:format=b,file=heap.bin
jmap -dump:file=c:dump.txt 340
Обратите внимание, что 340 — это pid java-процесса моей машины. Размер выгруженного файла превышает 10 мегабайт, и я только что открыл tomcat и запустил очень простое приложение без какого-либо доступа. Его можно представить на большом и загруженном сервере. , Насколько большим должен быть файл дампа? Что вам нужно знать, так это то, что информация о файле дампа очень примитивна и определенно не подходит для просмотра людьми напрямую, а содержимое, отображаемое jmap -histo, слишком простое, например, оно только показывает, сколько памяти занимают определенные типы объектов и количество этих объектов. , Но нет более подробной информации, например, кто создал эти объекты. Итак, какая польза от файла дампа? Конечно полезно, потому что есть инструмент для анализа файла дампа памяти jvm.
6: анализатор памяти eclipse
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
S0: Зона susvivor0 нового поколения, коэффициент использования площадей 54 . 62%
S1: область susvivor1 нового поколения, коэффициент использования пространства составляет 0,00% (поскольку второй второстепенный сбор не был выполнен)
Обновлено: 05.06.2023
В Java, начиная с 8 версии, появилась новая вариация OutOfMemory error : Metaspace.
Происходит это в связи с переполнением этой самой области памяти, которая является по сути эквивалентом Permanent Generation, однако может динамически расширяться.
Вопрос опытным товарищам:
Возникали ли у вас подобные ситуации в вашей практике, за исключением случаев, когда использовались сторонние библиотеки?
Вот тут еще в 2013 году описывали работу Metaspace с примером переполнения без использования сторонних библиотек. Попробуйте, может взлетит.
Распространённые причины
нехватка памяти, нужно не менее 400 мб
неустойчивое соединение с инетом
антивирус блокирует подключения джава в целом
ошибка проверки сертификата при работе с ssl, возможные решения
настройте правильно время на компьютере
джава установлена неправильно переустановите ее
антивирус блокирует проверку сертификата, отключите или по возможности настройте его правильно.
————
чё делать то. время у меня стоит правильное джаву переустановил, антивирус отрубил, всё равно не хочет загружать версию. я хочу загрузить версию майна фордж 1 17 1. но каждый раз мне выдаёт такую ошибку. я перезагружал комп и тлаунчер сам. ни чё не помогает. хотя другие версии форджа загружаются. но мне нужно 1 17 1 помогите что делать.
Zenker Искусственный Интеллект (103540) Это уже зависит от OVH и разрабов тдаунчера
Проверял ещё в момент падения серверов, проверил и сейчас. Работал, работает, и, дай Бог, будет работать.
В этой статье, мы бы хотели поделиться с вами объяснением большинства ошибок, которые может выдавать Minecraft во время запуска и подключения к серверам. Также мы приводим возможные варианты решения.
Ошибки связанные с вылетом Minecraft:
Bad Video Card Drivers – означает, что для вашей видеокарты не установлены, либо установлены слишком старые драйвера. Перейдите на сайт производителя и установите свежие драйвера.
Out of Memory – обычно Minecraft вылетает с этой ошибкой при нехватке оперативной памяти. Причиной может быть маленькое количество оперативной памяти, а также большое количество запущенных программ. Закройте все лишние программы. Если с памятью все ок, то ошибка возникает из за того что Java машине выделено мало памяти. Could not create the Java Virtual Machine — невозможно создать среду исполнения Java. Попробуйте обновить/переустановить Java.
Черный экран при запуске — вероятно, вы модифицировали minecraft.jar (установили мод, например), после чего он не прошел проверку на подлинность. Лечится обычно удалением папки META-INF из minecraft.jar
Ошибки связанные с серверами:
Bad Login, User not Premium – означает, что для входа на данный сервер требуется лицензия Minecraft. Если это ваш сервер, то отредактируйте файл server.properties, измените в нем значение online-mode=true на online-mode=false
The server responded with an invalid server key — проблема появилась в последних версиях Minecraft. Ошибку допустили разработчики игры. Решение проблемы мы описали в этой статье.
Connection reset — означает, что сервер обрубил ваше соединение. Обычно связано с недоступностью сервера, либо с проблемами в соединении.
Connection refused — сервер отклонил соединение. Означает, что по данному адресу нет запущенного сервера, либо имеются проблемы в соединении.
Read time out — вышло время ожидания ответа. Сервер и ваш клиент Minecraft общаются при помощи пакетов. Когда сервер либо клиент перестают отвечать на запросы (например у вас игра подвисла), выжидается какое то время (таймаут), после чего соединение обрубается. Сделано это для того, чтобы незаконченные висящие соединения закрывались и не создавали нагрузку.
Logged in from another location — кто-то зашел на сервер под вашим ником.
Internal Server Error — внутренняя ошибка сервера. Означает, что на сервере произошла какая-либо ошибка в выполняемом коде. Чаще появляется на самописных или модифицированных серверах.
Артем Буровцев
Руслан Фомичев
Артём, через много лет я понял что это из-за мира, созданного на каком-то снапшоте. Удалил мир, и ошибки уже не было
Читайте также:
- X rebirth скрипты как включить
- Как поменять язык на псп
- Как установить шкурки для world of tanks blitz на пк
- Вылетает при выходе из бара cyberpunk 2077
- Малиновка гта системные требования
The java.lang.OutOfMemoryError: Metaspace indicates that the amount of native memory allocated for Java class metadata is exausted. Let’s how this issue can be solved in standalone applications and cloud applications.
In general terms, the more classes you are loading into the JVM, the more memory will be consumed by the metaspace. In Java 8 and later, the maximum amount of memory allocated for Java classes (MaxMetaspaceSize) is by default unlimited, so in most cases there is no need to change this setting.
On the other hand, if you want to limit the amount of memory allocated for Java classes, you can set it as follows:
java -XX:MaxMetaspaceSize=3200m
The current Metaspace size (i.e. committed) will be, generally, smaller than that. Why ? Because there is a setting, MaxMetaspaceFreeRatio, which prevents the Metaspace from growing too much.
MaxMetaspaceFreeRatio is a JVM option that sets the percentage of free space that the JVM should attempt to maintain in the metaspace. When the percentage of free space in the metaspace drops below this threshold, the JVM will attempt to free up space by unloading classes that are no longer in use. The default value of MaxMetaspaceFreeRatio is 70.
In conclusion, setting a high value for MaxMetaspaceSize, increase the chances of OutOfMemoryError: Metaspace
What is the solution ?
By increasing the upper limit of the attribute MaxMetaspaceSize might solve the issue in some cases. For example, if you can see the error upon application start up.
On the other hand, if you see this error at runtime, we recommend to investigate on the Root cause of the problem before increasing blindly the MaxMetaspaceSize.
In order to find the Root cause, we recommend that you follow these steps:
- Understand how the JVM manages the MetaSpace data
- Learn how to monitor the MetaSpace in a running Java application
- Check the Heap dump of your application to find offending Classes
How Java Hotspot manages MetaSpace Data
The Java Hotspot manages Metadata space as follows: firstly, the JVM requests an amount of space to the OS. Then, this space is divided into chunks. A class loader allocates space for Metadata from its chunks.
Class Metadata is deallocated when the corresponding Java class is unloaded and its chunks are recycled for reuse or returned to the OS. Java classes are unloaded as a result of Garbage collection, and garbage collections may be triggered in order to unload classes and deallocate class Metadata. When the space committed for class Metadata reaches a certain threshold (a high-water mark), a Garbage Collection happens.
After the Garbage Collection, the high-water mark may change depending on the amount of space freed from class Metadata.
Monitoring the MetaSpace with jstat
The simplest way to monitor the MetaSpace size is by means of the jstat tool which is available in the JDK. When used with the option -gcmetacapacity it provides the following information:
jstat -gcmetacapacity (PID)
For example:
MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC FGCT CGC CGCT 0.0 374784.0 140360.0 0.0 253952.0 21168.0 23 0 0.000 6 0.046
And here is a description of the Labels:
- MCMN: Minimum metaspace capacity (kB).
- MCMX: Maximum metaspace capacity (kB).
- MC: Metaspace capacity (kB).
- CCSMN: Compressed class space minimum capacity (kB).
- CCSMX: Compressed class space maximum capacity (kB).
- YGC: Number of young generation GC events.
- FGC: Number of full GC events.
- FGCT: Full garbage collection time.
- GCT: Total garbage collection time.
Besides the Metaspace capacity, pay attention to the Compressed class space maximum capacity. The CompressedClassSpaceSize is the amount of virtual memory reserved for compressing Class MetaData. Therefore, MaxMetaspaceSize should be larger than CompressedClassSpaceSize.
If MaxMetaspaceSize is set smaller than CompressedClassSpaceSize, the JVM auto adjusts CompressedClassSpaceSize using this formula:
CompressedClassSpaceSize = MaxMetaspaceSize - 2 * InitialBootClassLoaderMetaspaceSize
Other interesting options include the parameter -gcutil:
$ jstat -gcutil (PID) | awk '{print($5)}'
This will print the Metaspace utilization as a percentage of the space’s current capacity.
Monitoring the MetaSpace with Java Native Memory tracking
Another option to monitor the MetaSpace usage is the JVM parameter NativeMemoryTracking, which you can add to the start up parameters. For example:
-XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=detail -XX:+PrintNMTStatistics
When you enable the Native Memory Tracking, you can request a report on the JVM memory usage using the following command:
$ jcmd <pid> VM.native_memory
If you check at the jcmd output, you will find at the bottom, the amount of native memory committed in the Internal (committed) section
Total: reserved=1334532KB, committed=369276KB - Java Heap (reserved=524288KB, committed=132096KB) (mmap: reserved=524288KB, committed=132096KB) - Class (reserved=351761KB, committed=112629KB) (classes #19111) ( instance classes #17977, array classes #1134) (malloc=3601KB #66765) (mmap: reserved=348160KB, committed=109028KB) ( Metadata: ) ( reserved=94208KB, committed=92824KB) ( used=85533KB) ( free=7291KB) ( waste=0KB =0.00%) ( Class space:) ( reserved=253952KB, committed=16204KB) ( used=12643KB) ( free=3561KB) ( waste=0KB =0.00%)
In the line beginning with Metaspace, look for the used value. This is the amount of space the JVM uses for loaded classes. The committed value is the amount of space available for chunks. The reserved value is the amount of space reserved (but not necessarily committed) for metadata.
Querying the Meta Space from an Heap Dump
To have more insights on the MetaSpace error, you should inspect the Heap of your Java application. You can use the jmap command line to trigger a Heap Dump:
jmap -dump:format=b,file=dump.hprof <PID>
Then, open the Heap Dump with your favourite tool. For example Eclipse MAT:
From the Heap Dump, you can look for duplicate classes, especially those loading your application classes.
The simplest way to do that, is using the OQL console. Within the OQL Console you can execute OQL queries to perform ad hoc analysis on your classes. For example, by executing the following query, you can have a list of class loaded from each Classloader:
select map(sort(map(heap.objects('java.lang.ClassLoader'), '{loader: it, count: it.classes.elementCount }'), 'lhs.count < rhs.count'), 'toHtml(it) + "
"')
This can be a precious hint to determine if a Classloader is loading an increasing number of classes.
OutOfMemoryError: Metaspace on OpenShift/Kubernetes
When using OpenJDK Image on OpenShift/Kubernetes, the default maximum value for the Metaspace is XX:MaxMetaspaceSize=100m. You might have noticed that setting this value through the JAVA_OPTIONS environment variable, doesn’t work as the default value is appended to the bottom:
VM Arguments: -Xms128m -Xmx1024m -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=256m -XX:AdaptiveSizePolicyWeight=90 -XX:MaxMetaspaceSize=100m -XX:+ExitOnOutOfMemoryError
The correct way to set the MaxMetaspaceSize is through the GC_MAX_METASPACE_SIZE environment variable. For example, if you are using a deployment.yaml file to deploy your application with JKube, the following settings will override the default values for the MaxMetaspaceSize and MaxMetaspaceSize:
spec:
template:
spec:
containers:
- env:
- name: JAVA_OPTIONS
value: '-Xms128m -Xmx1024m'
- name: GC_MAX_METASPACE_SIZE
value: 256
- name: GC_METASPACE_SIZE
value: 96
В Java, начиная с 8 версии, появилась новая вариация OutOfMemory error : Metaspace.
Происходит это в связи с переполнением этой самой области памяти, которая является по сути эквивалентом Permanent Generation, однако может динамически расширяться.
Вопрос опытным товарищам:
Возникали ли у вас подобные ситуации в вашей практике, за исключением случаев, когда использовались сторонние библиотеки?
задан 3 дек 2018 в 0:32
DonatelloDonatello
3954 серебряных знака16 бронзовых знаков
Вот тут еще в 2013 году описывали работу Metaspace с примером переполнения без использования сторонних библиотек. Попробуйте, может взлетит.
ответ дан 3 дек 2018 в 7:55
zoltzolt
1,5178 серебряных знаков15 бронзовых знаков
Join the DZone community and get the full member experience.
Join For Free
Recently we confronted an interesting java.lang.OutOfMemoryError: Metaspace problem in a microservice application. This microservice application will run smoothly for the initial few hours, but later it will start to throw java.lang.OutOfMemoryError: Metaspace. In this post, let me share the steps we pursued to troubleshoot this problem.
Different Types of OutOfMemoryError
JVM memory has the following regions:
- Young generation
- Old generation
- Metaspace
- Others region
When you encounter java.lang.OutOfMemoryError: Metaspace, it indicates that the Metaspace region in the JVM memory is getting saturated. Metaspace is the region where metadata details that are required to execute your application are stored. In a nutshell, it contains class definitions, method definitions, and other metadata of your application. To learn more about what gets stored in each of the JVM memory regions, you may refer to this video clip: JVM Memory — Learn Easily.
Note: There are 9 different types of java.lang.OutOfMemoryErrors. You can learn about those in the post «Flavors of OutOfMemoryErrors.» java.lang.OutOfMemroyError: Metaspace is one type of them, but not a common type.
Diagnose java.lang.OutOfMemoryError: Metaspace
Best place to start debugging the java.lang.OutOfMemoryError is the garbage collection log. If you haven’t enabled the garbage collection log for your application, you may consider enabling it by passing the JVM arguments mentioned here. Enabling a garbage collection log doesn’t add noticeable overhead to your application. Thus it’s recommended to enable garbage collection logs on all production JVM instances. Learn more about how to see the great benefits of a garbage collection log here.
We uploaded the garbage collection log of this troubled microservice application to the GCeasy-GC log analysis tool. Here is the GC log analysis report generated by the tool. Below is the Heap usage graph reported by the tool.
Heap usage graph reported by GCeasy
I would like to highlight a few observations from this graph:
- The red triangle in the graph indicates the occurrence of the Full Garbage Collection event. When the Full Garbage Collection event runs, it pauses your entire application. It tries to free up memory from all the regions (Young, Old, Metaspace) in the memory. You can see Full Garbage Collection events to be running consecutively from 12:30 am.
- Even though the maximum heap memory size is 2.5GB, Full Garbage Collection events were consecutively triggered even when heap memory usage is only at 10% (i.e., 250MB) of its maximum size. Typically, Full Garbage Collection events are consecutively triggered when heap memory grows to its maximum size. To understand why this happens, please review the next point.
- Below is the Metaspace region’s memory consumption graph from the report:
Metaspace usage graph reported by GCeasy
You can notice the Metaspace region’s memory consumption growing and dropping in a saw-tooth pattern until 12:30 am. After 12:30 am, the Metaspace region’s memory consumption isn’t dropping at all, even though Full GCs are consecutively running. It indicates garbage collection events aren’t able to free up Metaspace. It clearly indicates there is a memory leak in the Metaspace region.
Root Cause of java.lang.OutOfMemoryError: Metaspace
Now we have confirmed that a memory leak is happening in the Metaspace region. Therefore, the next logical step is to inspect the Metaspace region and try to understand what objects occupy this region. There are 5 different approaches to studying the contents in the Metaspace region. We went for the heap dump analysis approach.
Basically, we used the yCrash tool to capture the heap dump and analyze it. The tool instantly pointed out the problem: it was reporting a thread that was experiencing OutOfMemoryError. Apparently, this thread was experiencing OutOfMemoryError when invoking a 3rd party library. Due to a bug, this 3rd party library was creating new class definitions for every new request. This application was running on an older version of this 3rd party library. However, this bug was fixed in the latest version of the library. Once the 3rd party library was upgraded to the latest version, this problem got resolved.
Video
Java virtual machine
garbage collection
microservice
Published at DZone with permission of Ram Lakshmanan, DZone MVB.
See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
How AI Will Change Agile Project Management
-
How to LINQ Between Java and SQL With JPAStreamer
-
How To Use an Automatic Sequence Diagram Generator
-
Redefining DevOps: The Transformative Power of Containerization