Защо събирачът на боклук не извършва по-агресивно събиране на боклук по-рано от едноцифрен процент без купчина?

Това са моите настройки на Sun Hotspot 1.6 JVM heap в WebLogic 11g:

-Xms10g -Xmx10g -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:ParallelGCThreads=2 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:ConcGCThreads=2

Това, което виждам в графиката на JVM heap free % за 24 часа, е, че основно heap free % намалява с бавна скорост, докато достигнем около 9% (отнема около 24 часа). След това системата работи с нещо, което изглежда като пълен gc и се връща на 97%.

Има ли някаква настройка, която трябва да добавя/модифицирам, която ще каже на JVM да направи този пълен GC по-рано, отколкото когато станем под 10% свободно количество? напр. някаква настройка на съотношението?

Не създава проблеми, че изчаква, докато стигнем до 9% безплатно, но прави наблюдението/известяването по-трудно. В идеалния случай искаме да останем по-високи от да речем 30% безплатни по всяко време, така че ако паднем до тези едноцифрени числа, да знаем, че има някакъв проблем, напр. изтичане на памет.


java profiling garbage-collection
person BestPractices    schedule 11.10.2012    source източник
comment
Доколкото разбирам за събирането на боклука на java, той може да събира безплатно, когато иска, ако иска. Можете да се обадите на system.gc, за да кажете ръчно на събирача на отпадъци, че имате неща, които трябва да освободи, но gc не трябва да го прави.   -  person andre    schedule 11.10.2012
comment
Можете да използвате командата System.gc() за ръчно събиране на отпадъци.   -  person Tristan Hull    schedule 11.10.2012
comment
Трябва да погледнете колко памет е използвана/свободна след пълен GC. В противен случай свободното пространство не е полезно за наблюдение.   -  person Peter Lawrey    schedule 11.10.2012
comment
System.gc() не изпълнява окончателно събирача на боклук, той прави предложение да се стартира. Не е детерминистично.   -  person matt b    schedule 11.10.2012
comment
@BestPractices, предлагам да помислите повече за защо на този въпрос - мисля, че правите погрешно предположение, че наличието на ‹ 30% от свободната купчина показва изтичане на памет. Ако дадете на JVM X количество пространство в купчината, тя ще се стреми да използва възможно най-много от тази купчина - доколкото JVM знае, вие сте съгласни тя да използва до 10G пространство. По-добра индикация за изтичане е, когато пълните GC не могат да възстановят пространство или че количеството пространство, възстановено с времето, е все по-малко и по-малко - което не е толкова лесно за автоматично наблюдение.   -  person matt b    schedule 11.10.2012
comment
Не казвам, че показва изтичане на памет. Просто искам да започне да събира боклука по-рано, за да мога да задам по-добри прагове за наблюдение. В момента той пада до 9% безплатно (което отново отнема много време, за да се стигне до) и след това трябва да изчакам и да видя дали GC ще го върне до 97%. Предпочитам да прави по-чести пълни GC, отколкото каквото и да избере да прави в момента.   -  person BestPractices    schedule 11.10.2012

Отговори (2)


arrow_upward
2
arrow_downward

Намерих отговора с помощта на комбинация от други статии за stackoverflow.

-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=N

където N е приблизително какъв процент зает ще задейства пълен GC. По подразбиране е ~92, поради което виждам пълни GC на 9% безплатно. Превключването му на 65 работи за моя случай на употреба. Пълен GC се случва ~ 35% безплатно сега.

person BestPractices    schedule 11.10.2012

arrow_upward
0
arrow_downward

Какво ще кажете да премахнете: -Xms10g и след това да наблюдавате общия размер на купчината? Това също ще накара gc да работи по-често.

Ако вашето приложение наистина използва само 300MB RAM (3%), тогава изглежда крайно да започнете с разпределение на 10 Gigabyte.

person MTilsted    schedule 11.10.2012
comment
В кутията има 128GB рам. Може да работи и с 10 GB купчина. Има моменти, когато данните, които се изтеглят в приложението, са значителни (в GB), така че имаме нужда от допълнителни разходи. Започнахме с размера на купчината по подразбиране и след това го оразмерихме, за да отчетем грешките OutOfMemory при определени случаи на употреба. Така че максималния размер от 10gb остава. - person BestPractices; 11.10.2012
comment
Не искам да ви предлагам да промените максималната настройка. Коментирах -Xms10G, което означава: Започнете с разпределяне на 10g. Без това купчината ще започне да намалява и след това ще нарасне до 10 g, ако и когато имате нужда. Това би трябвало да направи мониторинга на използването на паметта много по-лесен - person MTilsted; 11.10.2012