Java garbage collection tempo "reale" è molto più grande di + "sistema" "utente"

Ecco come piena gc GC sguardi prolissi abilitati come -Java garbage collection tempo "reale" è molto più grande di + "sistema" "utente"

13463.547: [Full GC [PSYoungGen: 323053K->0K(325952K)] 
      [PSOldGen: 653170K->331738K(655360K)] 976224K->331738K(981312K) 
      [PSPermGen: 238715K->238715K(264448K)], 385.4631490 secs] 
      [Times: user=2.19 sys=1.35, real=385.50 secs]

Come può il tempo reale sia molto più grande di utenti + sys?

Il mio primo pensiero è stato che il garbage collector è in attesa di una risorsa, ma questa risorsa non sembra essere IO o CPU, poiché l'output "top" non mostra problemi di CPU o di memoria quando si verifica il gc.

fonte

2011-08-30 Artiom Gourevitch

Se non sta aspettando su IO e non è legato alla CPU, l'unica altra cosa che posso pensare è aspettare un semaforo/mutex, o davvero un accesso alla memoria lento. – Jonathan

usi JNI nella tua app? qual è la dimensione del tuo heap e quanta RAM fisica hai? – Ron

Xmx = 960 Mb, RAM = 4GB usiamo JNI ma non troppo spesso, in che modo JNI influenza la garbage collection? –

Per eseguire una raccolta completa, è necessario interrompere tutti i thread. (Uno dei motivi per cui chiama uno stop alla raccolta mondiale)

Fermare tutte le discussioni può richiedere molto tempo, specialmente se ne hai migliaia. Ogni thread deve raggiungere un "safepoint" per fermarlo.

Questo tipo di comportamento indica in genere troppi thread. Potresti anche considerare il collector ConcurrenntMarkSweep o il nuovo raccoglitore G1 che non ha bisogno di interrompere l'applicazione più spesso.

fonte

2011-08-30 16:39:30

Questo potrebbe essere un indizio. Il GC lungo si verifica negli ambienti QA, in cui l'agente Yourkit è abilitato. Potrebbe impedire che i thread raggiungano i punti di sicurezza, poiché prima avevamo problemi di prestazioni. –

Prova a leggere questo (più collegamenti inclusi nel white paper): Java 1.5 GC Internals.
Immagino che la maggior parte delle cose siano ancora valide per la VM 1.6 di Java e fornisce una visione approfondita di come funziona il GC. Inoltre, leggi questo: Tuning JVM's 1.6 Heap space
(c'è anche un altro link al white paper con un benchmark illustrativo ma non riesco a trovarlo :(:/
Proverò a vedere se compare da qualche parte ma immagino che sia situato da qualche parte nel sito Web di Oracle)

In generale, non spaventarti Provare e sperimentare diverse opzioni basate su alcune motivazioni e vedere come funziona. A meno che non si abbia un aumento delle prestazioni> del 10% e la tua applicazione sia critica prova per non mescolarsi a molti dettagli
Il motivo è semplice: un semplice codice riscritto in poche LOC può cambiare radicalmente il comportamento del tuo GC
Prenditi il tuo tempo e divertiti! :)

fonte

2011-08-30 17:28:55 Kounavi

Java garbage collection tempo "reale" è molto più grande di + "sistema" "utente"

risposta

Problemi correlati