Блог

Главная - Вопросы по программированию - Метапространство не хватает памяти даже на 20-30% или более свободного места

Метапространство не хватает памяти даже на 20-30% или более свободного места

#java #jboss #g1gc #metaspace

#java #jboss #g1gc #метапространство

Вопрос:

Сервер Keycloak / JBoss, работающий с использованием Java 8, был переключен на G1GC, а значение a -XX:MaxMetaspaceSize было установлено на 256 МБ. Вскоре он перестал отвечать на запросы, заполняя журналы ошибками OutOfMemory: Metaspace. Журналы GC не были включены. Сервер был подключен к службе мониторинга Dynatrace, которая показала наличие большого количества метапространства.

Из 256 МБ, выделенных в одном случае, было использовано 191 МБ. Из 256 МБ, выделенных во втором случае, использовано 165 МБ.

Я понимаю, что для освобождения метапространства был вызван GC, и, поскольку он не мог освободить достаточно места, он запускал GC после GC, поэтому имеет смысл, почему процесс застрял. Однако я не могу понять, почему процесс исчерпывал метапространство, даже когда много было свободно. Никаких других параметров JVM не было предоставлено (кроме XMS / XMX). Во всех разделах памяти кучи было много свободного места. Что-то пыталось выделить 60 МБ места в метапространстве? Это единственная возможная причина?

Комментарии:

1. Другой причиной может быть то, что вы смотрите на средние значения, а не на максимальные значения. Добавьте метрику метапространства в пользовательскую диаграмму и убедитесь, что выбрана «максимальная» агрегация. Возможно, тогда значения будут ближе к максимальным.

2. У вас UseCompressedClassesPointers включено? Если это так, то MaxMetaspaceSize = фиксированный размер (метапространство сжатое пространство классов). Вы можете не устанавливать его явно, но он включен по умолчанию, если UseCompressedOops включен. Итак, пожалуйста, проверьте свою конфигурацию.

3. @rmunge Это может быть возможно, но используемый размер mataspace, показанный в dynatrace, соответствует, что заставляет меня думать, что он не растет и не уменьшается.

4. @suv3ndu Это интересно, поскольку UseCompressedOops действительно был включен в аргументы JVM. Есть ли какая-либо документация / ссылка, где это объясняется?

5. @HarisMushtaq Пожалуйста, ознакомьтесь с этим для получения подробной информации.