Память не очищается в 2 последовательных полных циклах GC

1

Не в состоянии понять, что делает сборщик мусора, я вижу, что 3 полных цикла GC только в первом цикле очистили некоторую память, другая 2-х тактовая память не очищается, но в каждом цикле она занимает 16 секунд.

1189.994: [GC1189.994: [ParNew: 446787K->22515K(471872K), 0.1136668 secs] 1408852K->990343K(4141888K), 0.1144236 secs] [Times: user=0.87 sys=0.01, real=0.11 secs] 
1204.825: [Full GC1204.826: [CMS: 967828K->695710K(3670016K), 20.8721088 secs] 1192388K->695710K(4141888K), [CMS Perm : 133862K->133237K(524288K)], 20.8732268 secs] [Times: user=20.81 sys=0.13, real=20.87 secs] 
1225.703: [Full GC1225.703: [CMS: 695710K->695710K(3670016K), 16.7364748 secs] 695716K->695710K(4141888K), [CMS Perm : 133237K->133237K(524288K)], 16.7373018 secs] [Times: user=16.77 sys=0.01, real=16.74 secs] 
1242.444: [Full GC1242.444: [CMS: 695710K->695710K(3670016K), 16.4691631 secs] 695727K->695710K(4141888K), [CMS Perm : 133237K->133237K(524288K)], 16.4698573 secs] [Times: user=16.51 sys=0.02, real=16.47 secs] 
1283.740: [GC1283.741: [ParNew: 419456K->33117K(471872K), 0.1520895 secs] 1115166K->728827K(4141888K), 0.1531085 secs] [Times: user=1.06 sys=0.01, real=0.15 secs]

Ежедневно я вижу это в gc.log и, и каждый раз 2 цикла бесполезны.

Параметры vm

java -server -Xms4096m -Xmx4096m -XX:PermSize=512m
-XX:MaxPermSize=512m -XX:MaxNewSize=512m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseMembar -d64 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:GC.log -classpath ......

Доступные процессоры (ядра): 16

Edit: Я думал об удалении параметра MaxNewSize, так как теперь он составляет 1/8 части полной кучи. И я читал в нескольких статьях, что он должен составлять от 1/3 до 1/4 от общей кучи. Но я получаю правильное объяснение, как размер молодого поколения (MaxNewSize) повлияет на GC.

Теги:
garbage-collection
jvm
java-7

2 ответа

0

Глядя в журналы GC, мне приходит в голову немного вещей

  1. В этом случае старая десятка не полна 695 МБ из более чем 3 ГБ. Итак, почему GC триггеры? Несколько циклов GC работают, но не собирают ничего из perm или старого поколения. Может ли это из-за ручного запуска? Помните, что полные GC запускаются, когда куча старого поколения имеет фрагментацию (так что продвижение по службе сложно) или InitatingHeapOccupancyPercent установлен слишком низко. По умолчанию для JVM установлено значение 45. Вы можете установить это на -XX: + InitatingHeapOccupancyPercent = 70
0

Похоже, что объекты все еще активны и до сих пор имеют ссылки на них. Вы можете исправить это, перемещаясь туда, где вы объявляете и инициализируете свои объекты/переменные. Это не всегда возможно, так как это может повлиять на работу программы. Имейте в виду, что сбор мусора не всегда освобождает место, он освобождает пространство, которое может быть освобождено.

Есть ли причина, по которой вы думаете, что пространство должно быть освобождено? Вы вручную запускаете сборщик мусора или это просто автоматический запуск?

  • 0
    Этот журнал взят из моей тестовой среды, и когда я использовал инструмент, над этим приложением работало около 50 человек. Если не было ничего, чтобы освободить, почему Java будет начинаться полный 3 раза?
  • 0
    Есть несколько вещей, которые могут заставить работать GC. Во-первых, кто-то может запустить его вручную. Вы написали весь код, о котором идет речь, содержит ли он какие-либо ручные прогоны? GC также хранит данные в поколениях и выполняет некоторое сжатие памяти, поэтому он может инициировать выполнение одной из этих операций. Я не знаю запутанных особенностей GC, но я предполагаю, что есть случаи, которые могут заставить его работать и ничего не удалять. Посмотрите здесь, чтобы увидеть больше информации о GC oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/…
Показать ещё 2 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню