Како да се намали неуспехот на Java-конкурентот и прекумерниот режим на gc
Во Јава, неуспех во истовремен режим значи дека конкурентскиот колекционер не успеа да ослободи доволно мемориски простор од постојан и постојан вид и мора да се откаже и да дозволи gc целосно да застане од светот. крајниот резултат би можел да биде многу скап.
Го разбирам овој концепт, но никогаш не сум имал добро сеопфатно разбирање за А) што истовремено може да предизвика неуспех и Б) Кое е решението ?.
Овој вид на двосмисленост ме тера да го пишувам/решавам проблемите со кодот без премногу предлози и честопати морам да купувам околу знамињата за изведба од Фу до Бар без посебна причина, само треба да се обидам.
Би сакал да научам од развивачите овде какво е вашето искуство? Ако наидете на проблем со изведбата, што беше причината и како му пристапивте?
Ако имате препораки за кодирање, немојте да бидете премногу општи. Благодарам!
4 одговори
Првото нешто што го научив за CMS е дека му треба повеќе меморија од другите собирачи, околу 25-50% повеќе е добра почетна точка. Ова ви помага да избегнете фрагментација, бидејќи CMS не прави никакво набивање, како што е запирање на глобалното собирање. Второ, направете работи што му помагаат на собирачот на ѓубре; Integer.value Наместо новиот Integer, ослободете се од анонимните класи, проверете дали внатрешните класи не пристапуваат до недостапни работи (приватни во надворешната класа). Колку помалку ѓубре, толку подобро. Пронајдете грешки и да не ги игнорирате предупредувањата ќе помогнат многу во ова.
Кога станува збор за подесување, открив дека треба да пробате неколку работи:
Му кажува на JVM да користи CMS во жанрот на издржана форма.
Точна големина на купот: -Xmx2048m -Xms2048m Ова го спречува GC да прави работи како зголемување и намалување на купот.
Користете паралелна наместо сериска колекција во помладата генерација. Ова ќе ги забрза вашите помали колекции, особено ако имате поставено многу голем млад пол. Голема млада генерација е генерално добра, но не надминува половина од стариот пол.
поставете го бројот на нишки што CMS ќе ги користи при правење работи што можат да се прават паралелно.
-XX: + CMSParallelRemarkEnabled забелешката е стандардно сериска, ова може да ве забрза.
-XX: + CMSIncrementalMode овозможува апликацијата да работи подолго со префрлување на GC помеѓу фазите
-XX: + CMSIncrementalPacing дозволува JVM да ја смени промената на фреквенцијата на собирање со текот на времето
-XX: CMSIncrementalDutyCycleMin = X Минимален износ на време поминато во ГК
-XX: CMSIncrementalDutyCycle = X Започнете со GC овој% од времето
-XX: CMSIncrementalSafetyFactor = X
Открив дека обично можете да добиете кратки периоди на пауза ако ги поставите така што тие секогаш се собираат. Бидејќи повеќето работи се прават паралелно, ќе достигнете обично предвидливи паузи.
-XX: CMSFullGCsBeforeCompaction = 1
Ова е многу важно. Му кажува на колекционерот CMS секогаш да ја комплетира колекцијата пред да започне нова колекција. Без ова, можете да влезете во ситуација да фрлите многу работа и да започнете повторно.
Стандардно, CMS ќе дозволи вашиот PermGen да расте додека не ја убие вашата апликација за неколку недели од сега. Ова запира. Вашиот PermGen ќе се зголеми само ако користите Reflection или користите String.intern погрешно или направите нешто погрешно со натоварувач на класа или нешто друго.
Преживеаниот исто така може да се игра во зависност од тоа дали имате предмети со долг или краток живот и колку е да го копирате објектот помеѓу просторите за преживеан со кои можете да живеете. Ако знаете дека сите ваши предмети ќе останат наоколу, можете да ги конфигурирате просторите за преживување со нула големина и сè што ќе преживее колекција на млади жанрови ќе биде веднаш достапно.
Неуспехот на истовремен режим може или да се избегне со зголемување на бројот на придружни генерации или започнување на собирање на CMS на помал капацитет со поставување на CMSInitiationOccupancyFaction на помала вредност
Меѓутоа, ако навистина има истекување на меморија во вашата апликација, вие само купувате време.
Ако ви треба брзо рестартирање и закрепнување и претпочитате "брз" пристап, јас би предложил да не користите CMS воопшто. Јас би се борел со '-XX: + UseParallelGC'.
Паралелниот собирач на ѓубре (UseParallelGC) исфрла исклучок од меморијата ако е преголемо време кога собрал мала количина од купот. За да го избегнете овој исклучок, можете да ја зголемите големината на депонијата. Може да ги поставите параметрите -XX: GCTimeLimit = временско ограничување и -XX: GCHeapFreeLimit = простор-ограничување
Понекогаш ООМ доста брзо и беше убиен, понекогаш страдајќи долго време (последниот период беше над 10 часа).
Ми се чини дека истекувањето на меморијата е во основата на твоите проблеми.
Неуспехот во СМС нема да предизвика ООМ (како што го разбирам). Наместо тоа, се случува дефект на CMS затоа што JVM треба да прави премногу колекции премногу брзо, а CMS не може да биде во тек. Ситуација каде што се случуваат многу циклуси на наплата за краток временски период е кога вашата депонија е скоро полна.
Навистина долгото време на бучава звучи чудно. но теоретски е можно ако вашиот автомобил се движи ужасно. Сепак, долг период на повторување на CGs е сосема веродостојно ако депонијата ви е скоро полна.
Може да го конфигурирате GC да паѓа кога депонијата е 1) во целосна големина и 2) сè уште е близу до целосна по завршувањето на целосниот GC. Обидете се да го направите ова ако веќе не сте го сториле тоа. Нема да ги реши проблемите, но барем вашиот JVM ќе добие OOM брзо, овозможувајќи ви да ја рестартирате и вратите услугата побрзо.
издание - опцијата да го направите ова е -XX: GCHeapFreeLimit = nnn каде nnn е број помеѓу 0 и 100 со што се дава минималниот процент на грамадата што мора да биде слободен по GC. Стандардно е 2. Опцијата е наведена на соодветно насловената страница „Најкомплетната листа на -XX опции за Java 6 JVM“. (Постојат многу -XX опции наведени таму, кои не се појавуваат во документацијата за Сонцето. За жал, страницата дава неколку детали за тоа што всушност прават опциите.)
Веројатно треба да започнете да барате дали апликацијата/webapp има протекување на меморија. Ако е така, вашите проблеми нема да исчезнат доколку не бидат пронајдени и поправени. На долг рок, управувањето со опциите Hotspot GC нема да ги поправи протекувањата на меморијата.