Java G1 garbage collection in produzione

https://stackoverflow.com/questions/2254041

20-09-2019
|

Domanda

Dal momento che Java 7 sta per usare la nuova raccolta dei rifiuti G1 di default è Java sta per essere in grado di gestire un ordine di grandezza più grande mucchio senza presunti volte GC pausa "devastanti"? Qualcuno ha effettivamente implementato G1 nella produzione, quali sono state le tue esperienze?

Per essere onesti l'unica volta che ho visto davvero pause lunghe GC è molto grandi cumuli, molto di più di una stazione di lavoro avrebbe. Per chiarire la mia domanda; sarà G1 aprire la porta d'ingresso al cumuli di centinaia di GB? TB?

Soluzione

Sembra che il punto di G1 è di avere tempi di pausa più piccoli, fino al punto in cui si ha la possibilità di specificare un obiettivo massimo tempo di pausa.

Garbage Collection non è solo un semplice "Hey, è pieno, passiamo tutto in una volta e ricominciare da capo" trattare più - è incredibilmente complesso multi-livello, sistema, fondo filettato. Si può fare molto della sua manutenzione in background senza pause a tutti, e utilizza anche la conoscenza dei modelli attesi del sistema in fase di esecuzione per aiutare -. Assumendo come la maggior parte degli oggetti morire proprio dopo essere stato creato, etc

Direi volte GC pausa stanno per continuare a migliorare, non peggiorare, con le versioni future.

EDIT:

a ri-lettura mi venne in mente che io uso quotidiano Java - Eclipse, Azureus, e le applicazioni che sviluppo, ed è stato un momento da tempo ho visto una pausa. Non una pausa significativa, ma voglio dire alcuna pausa a tutti.

Ho visto pause quando right-click su Windows Explorer o (a volte) quando mi collego certo hardware USB, ma con Java --- nessuno a tutti.

È GC ancora un problema con qualcuno?

Altri suggerimenti

ho provato fuori con un'applicazione pesante: 60-70GB assegnata a heap, con 20-50GB in uso in qualsiasi momento. Con questo tipo di applicazioni, è un eufemismo per dire che la situazione potrebbe essere diversa. Io corro JDK 1.6_22 su Linux. Le versioni minori sono importante-- prima circa 1.6_20, c'erano insetti in G1 che hanno causato NullPointerExceptions casuali.

ho scoperto che è molto bravo a tenere entro la pausa bersaglio si dà maggior parte del tempo. Il valore di default sembra essere un (secondo 0.1) pausa 100 ms, e ho raccontato che faccia metà (XX: MaxGCPauseMillis = 50). Tuttavia, una volta che si fa veramente poca memoria, è panico e fa un garbage collection completa stop-il-mondo. Con 65 GB, che prende tra 30 secondi e 2 minuti. (Il numero di CPU, probabilmente non fa la differenza;. È probabilmente limitata dalla velocità del bus)

Rispetto al CMS (che non è il GC server predefinito, ma dovrebbe essere per i server web e altre applicazioni in tempo reale), le pause tipiche sono molto più prevedibili e possono essere resi molto più breve. Finora mi sto avendo più fortuna con CMS per le enormi pause, ma che potrebbe essere casuale; Sto vedendo loro solo un paio di volte ogni 24 ore. Non sono sicuro di quale sarà più appropriato nel mio ambiente di produzione in questo momento, ma probabilmente G1. Se Oracle mantiene tuning, ho il sospetto G1 alla fine sarà il vincitore chiaro.

Se non hai un problema con i netturbini esistenti, non c'è motivo di prendere in considerazione G1 al momento. Se si esegue un'applicazione a bassa latenza, come ad esempio un'applicazione GUI, G1 è probabilmente la scelta giusta, con MaxGCPauseMillis set davvero basso. Se si sta eseguendo un'applicazione in modalità batch, G1 non si compra nulla.

Anche se non ho ancora testato G1 nella produzione, ho pensato di commentare che GC sono già problematico per i casi senza cumuli "humongous". servizi specificamente con un solo, diciamo, 2 o 4 GB possono essere gravemente influenzati da GC. GC giovani generazione non sono di solito problematico, in quanto arrivano millisecondi a una cifra (o al massimo due cifre). Ma collezioni di vecchia generazione sono molto più problematico, in quanto prendono più secondi con vecchi-gen dimensioni di 1 giga o superiore.

Ora: in teoria CMS può aiutare molto lì, come è possibile eseguire la maggior parte del suo funzionamento in concomitanza. Tuttavia, nel corso del tempo ci saranno casi in cui non può fare questo e deve ricadere collezione "fermare il mondo". E quando ciò accade (dopo, diciamo, 1 ora - non spesso, ma ancora troppo spesso), beh, mantenere il vostro f *** ing cappelli. Si può prendere un minuto o più. Questo è particolarmente problematico per i servizi che cercano di limitare al massimo la latenza; invece di esso prendere, per esempio, 25 millisecondi per servire una richiesta ora vogliono dieci secondi o più. Per aggiungere danno a clienti insultare sarà poi spesso tempo la richiesta e riprovare, portando a ulteriori problemi (alias "merda tempesta").

Questo è un settore in cui G1 sperava di aiutare un sacco. Ho lavorato per una grande società che offre servizi cloud per l'archiviazione e il messaggio di dispacciamento; e non abbiamo potuto utilizzare CMS in quanto, anche se gran parte del tempo ha funzionato meglio di varietà parallele, aveva questi crolli. Così, per circa un ora le cose erano belle; e poi roba colpito il ventilatore ... e perché il servizio è basata su cluster, quando un nodo messo nei guai, altri tipicamente seguita (dal timeout GC-indotta portano ad altri nodi credere nodo era precipitato, che porta a ri-routes).

Non credo GC è che molto di un problema per le applicazioni, e forse anche i servizi non cluster sono meno spesso colpiti. Ma sempre più i sistemi sono raggruppati (esp., Grazie a negozi di dati NoSQL) e le dimensioni di heap sono in crescita. OldGen GC sono super-linearmente correlata alla dimensione heap (il che significa che il raddoppio dimensione heap più che raddoppia il tempo GC, assumendo dimensioni dei dati in tempo reale impostato anche raddoppia).

di Azul CTO, Gil Tene, ha una bella visione d'insieme dei problemi connessi con Garbage Collection e una revisione di varie soluzioni nella sua Understanding Java Garbage Collection e cosa si può fare al riguardo presentazione, e non c'è ulteriore dettaglio in questo articolo: http://www.infoq.com/articles/azul_gc_in_detail .

C4 Garbage Collector di Azul nel nostro Zing JVM è sia parallelo e simultaneo, e utilizza lo stesso meccanismo GC sia per le nuove e vecchie generazioni, che lavorano contemporaneamente e compattazione in entrambi i casi. Ancora più importante, C4 non ha alcun arresto-il-mondo ripiegare. Tutti compattazione viene eseguita in concomitanza con l'applicazione in esecuzione. Abbiamo clienti che eseguono molto grandi (centinaia di GByte) con caso peggiore volte GC pausa di <10 ms, e in base all'applicazione spesso meno di 1-2 msec.

Il problema con CMS e G1 è che ad un certo punto Java memoria mucchio deve essere compattato, e entrambe le munnizzari stop-il-mondo / STW (cioè sospendere l'applicazione) per eseguire la compattazione. Così, mentre CMS e G1 possono spingere fuori STW fa una pausa, non eliminarli. C4 di Azul, tuttavia, non eliminare completamente le pause STW ed è per questo Zing ha così basso GC pause anche per dimensioni di heap gigantesche.

E per correggere una dichiarazione fatta in una precedente risposta, Zing non richiede alcuna modifica al sistema operativo. Funziona proprio come qualsiasi altra JVM su distribuzioni Linux non modificati.

Stiamo già utilizzando G1GC, da quasi due anni. Il suo andando alla grande nel nostro sistema di elaborazione delle transazioni mission-critical, e 'dimostrato di essere un grande supporto w.r.t alto rendimento, bassi pause, la concorrenza e la gestione della memoria ottimizzata pesante.

Stiamo utilizzando le seguenti impostazioni JVM:

-server -Xms512m -Xmx3076m -XX:NewRatio=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:+AggressiveOpts -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000 -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime

Aggiornamento

-d64 -server -Xss4m -Xms1024m -Xmx4096m -XX:NewRatio=50 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:-DisableExplicitGC -XX:+AggressiveOpts -Xnoclassgc -XX:+UseNUMA -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+UseStringDeduplication -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000

Il collettore G1 riduce l'impatto delle collezioni complete. Se si dispone di un'applicazione in cui si è già ridotto la necessità per le collezioni complete, il Concurrent mappa Sweep collettore è altrettanto buona e nella mia esperienza ha più brevi tempi di incasso minori.

Sembra G1 partire JDK7u4 è finalmente ufficialmente supportato, vedere la RN per JDK7u4 http://www.oracle.com/technetwork/java/javase /7u4-relnotes-1575007.html.

Dal nostro test ancora per i grandi JVM sintonizzati CMS agisce ancora meglio di G1 ma credo che crescerà meglio.

CMS può portare a prestazioni lentamente degradato anche se si esegue senza accumulare oggetti di ruolo. Questo a causa della frammentazione della memoria che evita G1 presumibilmente.

Il mito G1 disponibile solo con il supporto a pagamento è proprio questo, un mito. Sun e ora Oracle hanno chiarito questo sulla pagina JDK.

G1 GC dovrebbe funzionare meglio. Ma se l'impostazione XX: MaxGCPauseMillis troppo aggressivo, spazzatura sarà raccogliendo troppo lentamente. Ed è per questo piena GC scatta nel l'esempio di David Leppik.

Ho appena implementato G1 Garbage Collector nel nostro progetto Terracotta Big memoria. Mentre si lavora su diversi tipi di collettori G1 ci ha dato i migliori risultati con meno di 600ms tempo di risposta.

È possibile trovare i risultati del test (26 in totale) qui

Speranza che aiuta.

Recentemente ho spostato da

CMS per G1GC con 4G mucchio e processore a 8 core su server con JDK 1.7.45 .

(JDK 1.8.x G1GC è preferito su 1.7, ma a causa di alcune limitazioni, devo attenersi a 1.7.45 versione)

Ho configurato sotto parametri chiave e mantenuto tutti gli altri parametri ai valori di default.

-XX:G1HeapRegionSize=n, XX:MaxGCPauseMillis=m, -XX:ParallelGCThreads=n, 
-XX:ConcGCThreads=n apart from -Xms and -Xmx

Se si vuole mettere a punto questi parametri, dare un'occhiata a questo articolo oracle .

Osservazioni fondamentali:

L'utilizzo della memoria è coerente con G1GC a differenza di alta e bassi con CMS
Max GC tempo di pausa è inferiore rispetto al CMS
Il tempo trascorso in Garbage Collection è po 'alto in G1GC rispetto al CMS.
Numero di importanti collezioni sono quasi trascurabile rispetto al CMS
Numero di collezioni minori sono sull'estremità superiore rispetto a CMS

Ma ancora sono felice che Max GC tempo di pausa è inferiore al CMS. Ho impostato Max GC tempo di pausa come 1,5 secondi e questo valore non è stato ancora superato.

SE connessa interrogazione:

Java 7 (JDK 7 ) raccolta dei rifiuti e la documentazione sul G1

Ho recentemente migrato parte di Twicsy ad un nuovo server con 128 GB di RAM e ha deciso di usare 1.7. Ho iniziato con le stesse impostazioni della memoria come facevo con 1.6 (ho diverse istanze in esecuzione facendo varie cose, ovunque da 500MB di cumulo fino a 15 GB, e ora una nuova con 40GB) e che non ha funzionato bene a tutti . 1.7 sembra utilizzare più mucchio di 1,6, e ho sperimentato un sacco di problemi nel corso dei primi giorni. Per fortuna ho avuto un sacco di RAM con cui lavorare e urtato la RAM per la maggior parte dei miei processi, ma ancora stavo avendo alcuni problemi. Il mio normale MO è stato quello di utilizzare una dimensione molto piccola minima mucchio di 16m, anche con un mucchio massimo di diversi gigabyte, quindi accendere GC incrementale. Ciò ha mantenuto le pause al minimo. Che non funziona ora, però, e ho dovuto aumentare la dimensione minima a circa quello che mi aspettavo da utilizzare, in media, nel mucchio, e che ha funzionato molto bene. Ho ancora GC incrementale acceso, ma sarò provare senza. Pause di sorta ora, e le cose sembrano essere in esecuzione molto veloce. Quindi, credo che la morale della storia è non aspettatevi le impostazioni della memoria da tradurre perfettamente 1,6-1,7.

G1 rende l'applicazione molto più agile: il latancy dell'applicazione alzerà - l'applicazione può essere denominato come "-soft real-time". Questo viene fatto sostituendo due tipi di piste GC (piccoli minori e una grande su Tenured Gen) per uguali dimensioni piccole.

Per maggiori dettagli un'occhiata a questo: http://geekroom.de/java/java-expertise-g1- fur-java-7 /

Sto lavorando con Java, per piccoli e grandi Heap, e la questione del GC e GC completa appare ogni giorno, come i vincoli possono essere più severi rispetto ad altri: in certo ambiente, 0,1 secondi di GC spazzino o Full GC, di uccidere semplicemente il Fonctionnalité, e ha fini di configurazione granulare e la capacità è importante (CMS, iCMS, altri ... l'obiettivo è qui per avere il miglior tempo di risposta possibile con il trattamento tempo quasi reale (qui il trattamento in tempo reale è spesso 25 ms), quindi, in sostanza, i miglioramenti in GC ergonomia ans heuristique sono i benvenuti!

Io uso G1GC su Java 8 ed anche con Groovy (anche Java 8), e sto facendo vari tipi di carichi di lavoro, e iale G1GC funziona in questo modo:

L'utilizzo della memoria è molto bassa, ad esempio 100MB invece di 500MB rispetto alle impostazioni di default di Java
Il tempo di risposta è coerente e molto bassa
La performance tra le impostazioni predefinite e G1GC è del 20% quando si utilizza il rallentamento G1GC nel peggiore dei casi (senza messa a punto, l'applicazione single-threaded). Non è molto considerando buon tempo di risposta e di utilizzo della memoria bassa.
Quando si esegue da Tomcat che è multi-thread, le prestazioni complessive è migliore del 30% e l'utilizzo della memoria è molto più basso come pure i tempi di risposta sono molto più bassi.

Quindi, in generale, quando si utilizza in realtà diversi carichi di lavoro, G1GC è molto buono collettore per Java 8 per le applicazioni multi-threaded, e anche per i single-threaded ci sono alcuni vantaggi.

Non è consigliabile utilizzare java8 w / G1GC per il calcolo punto galleggiante con JVM hotspot-like. E 'pericoloso per l'integrità e precisione di applicazione.

https://bugs.openjdk.java.net/browse/JDK-8148175

JDK-8165766

JDK-8186112

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow