Java процесс занимает 90% пространства подкачки - PullRequest
Новая
       16

Java процесс занимает 90% пространства подкачки

1 голос
/ 07 февраля 2020

У меня есть приложение, которое имеет выделенную память кучи 20 ГБ. Но даже если память Heap используется почти или менее чем на 50%, пространство подкачки моего сервера полностью израсходовано. Java - это процесс, который потребляет 90% подкачки.

Подкачка освобождается только после перезапуска приложения с предупреждением ниже. Нужно выяснить причину root и любое влияние, связанное с этим. Не запустится ли мое приложение, если подкачка заполнена?

Предупреждение, которое я вижу при запуске приложения в журналах :

Недостаточно памяти для Java Среда выполнения, чтобы продолжить. При выделении собственной памяти (mmap) не удалось сопоставить 17895718912 байт для фиксации зарезервированной памяти. Превышен лимит пространства подкачки или ресурса кучи (проверка с ограничениями или ulimit)? Создается отчет об ошибке с дополнительной информацией, который сохраняется в виде файла по следующему адресу: /XX/myapp/apache-tomcat-7.0.90/bin/hs_err_pid86282.log 2020-01-14T05: 17: 18.742 + 0100 [INFO] [os c .s.PostProcessorRegistrationDelegate $ BeanPostProcessorChecker] Bean '(внутренний компонент) # 1814a032' типа [org.springframework.aop.aspectj.AspectJAroundAdvice] не подходит для обработки всеми компонентами BeanPostProcessors ( не подходит для авто-проксирования) *** Предупреждение: не удалось выполнить INFO: os :: commit_memory (0x00000003fjgh0000, 17895718912, 0); error = 'Недостаточно места' (errno = 12) Недостаточно памяти для продолжения среды выполнения Java. При выделении собственной памяти (mmap) не удалось сопоставить 17895718912 байт для фиксации зарезервированной памяти. Превышен лимит пространства подкачки или ресурса кучи (проверка с ограничениями или ulimit)? Создается отчет об ошибке с дополнительной информацией, который сохраняется в виде файла в этом месте:

Мои свойства JVM : 

/XX/java/bin/java -Djava.util.logging.config.file=/XX/myapp/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -javaagent:/xx/myapp/newrelic/newrelic.jar -Djdk.tls.ephemeralDHKeySize=2048 -Xms20g -Xmx20g -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -Djava.net.preferIPv4Stack=true -Dignore.endorsed.dirs= -classpath /XX/myapp/tomcat/bin/bootstrap.jar:/XX/myapp/tomcat/bin/tomcat-juli.jar -Dcatalina.base=/XX/myapp/tomcat -Dcatalina.home=/XX/myapp/tomcat -Djava.io.tmpdir=/XX/myapp/tomcat/temp org.apache.catalina.startup.Bootstrap start

Использование подкачки при проверено для каждого процесса, его Java, который использует 90% Swap

1 Ответ

1 голос
/ 12 февраля 2020

Ваш Java процесс выполнен , а не только из памяти кучи, посмотрите это для хорошего примера .

Теперь вы говорите, что у вас есть 28GB ОЗУ, из которого вы выделяете 20GB для кучи только . Вы не только резервируете виртуальную память, но и делаете ее через AlwaysPreTouch (теперь я сомневаюсь, что вы даже понимаете, что это делает). Таким образом, ваша ОС отображает 20GB ОЗУ в вашем процессе (упрощенное объяснение).

Даже если вы видите, что занят только 50%, используемый вами сборщик мусора - не освобождает память обратно в ОС, поэтому все 20GC равны всегда занят и не может быть повторно использован каким-либо другим процессом. Таким образом, бессмысленно измерять или контролировать кучу.

Ваш процесс завершается с ошибкой Native memory allocation (mmap) failed to map..., как сказано, это не связано с кучей. Сбой в родной памяти , это != куча. Я также не знаю специфику вашего приложения, но -XX:+DisableExplicitGC не может быть хорошим вариантом; вместо этого вы можете включить параллельный вызов (если ваш G C поддерживает это) через -XX:+ExplicitGCInvokesConcurrent.

Похоже, вы также используете CMS сборщик мусора, который устарел.

...