2012-04-09 12 views
6

Vedo che con -Xmx2g, la memoria di picco raggiunge 1G e fa le raccolte principali (collettore di marksweep). Con -Xmx3g, raggiunge 1.5G e fa una collezione importante. Con -Xmg4g, raggiunge il 2G e fa importanti collezioni. Ma da qui ho provato ad aumentare la memoria massima a 6G, 8G, 12G e tutte le volte che la memoria di picco raggiunge 2G fa le raccolte principali.L'utilizzo della memoria di picco non va oltre il limite

Come utilizzarlo oltre il 2G? Non ho incontrato nessun setting per questo. -Xms conta qui? Per quelli -Xmx, ho fatto -Xms a metà di -Xmx.

Sto usando Jetty, Java 1.6.024.

UPDATE: Sì, sto usando JVM a 64 bit. Le opzioni JVM che sto usando sono: -Xmx6g -Xms3g -XX: MaxPermSize = 256m Il modo in cui sto determinando il picco di memoria è guardando il grafico della memoria in JConsole. Raggiunge 2G e gocce (raccolta maggiore). Old Gen raggiunge 1,5 G max e quindi si verifica un calo.

Grazie, Carrozzine.

+4

È giusto presupporre che si stia utilizzando una JVM a 64 bit? Vale la pena chiedere, perché la JVM a 32 bit ha un limite di dimensioni di 2 GB integrato. – duffymo

+0

Penso che sia sicuro dire che è una JVM a 64 bit, perché Java terminerà senza eseguire il programma se si specifica una dimensione heap molto più grande di 1500 m (il limite esatto dipende da JVM). – rob

+0

Hai provato a giocare con le proprietà -XX? –

risposta

1

Si dispone di tre aree di memoria, eden, superstite e spazio occupato.

Quello che sospetto sia che gli eventi siano gli spazi di tenero o di eden non crescono mentre aumenti la dimensione massima.

Il motivo per cui queste due regioni sono importanti è che quando lo spazio occupato riempie viene attivato un GC completo (sospetto che questa dimensione sia in aumento) Quando lo spazio eden si riempie e non c'è spazio sufficiente nello spazio sopravvissuto per copiare tutti gli oggetti a sinistra, viene attivato anche un GC completo.

Se questa è la causa del problema, si sta creando un numero molto elevato di oggetti di media durata che potrebbe rappresentare un problema di prestazioni, a meno che non sia possibile ridurre il numero creato. Un'alternativa è specificare una nuova dimensione più grande che aumenta la dimensione di eden.

Prova -mx12g -XX:NewSize=10g - verbosegc

L'ultima opzione darà ai vostri le dimensioni dei singoli spazi quando sono puliti.

+0

Peter, grazie per la risposta. Ho una domanda di follow-up. Una dimensione mantenuta dell'oggetto è di circa 4 MB. E creiamo uno di questi oggetti al minuto e lo sostituiamo con un oggetto di un minuto precedente in una ConcurrentHashMap statica. Per quanto posso vedere questo è l'oggetto più grande.Ovviamente ci sono molti altri oggetti String e altri oggetti temporanei, ma sono tutti molto più piccoli di 4 MB. È troppo grande per uno spazio Eden in 3G? Perché quando ho avuto 6G, ho provato con NewRatio di 1 e questo non ha aiutato l'utilizzo di picco per andare oltre 2G. Grazie. – prams

+0

Gli oggetti di grandi dimensioni sono assegnati direttamente allo spazio di possesso. Se si dispone di un oggetto che è in realtà costituito da un sacco di piccoli oggetti che poi dovrebbero essere assegnati allo spazio eden. Per oggetti di grandi dimensioni come questo, è meglio riciclarli da soli se puoi in modo semplice. –

+0

L'impostazione di NewSize su grandi dimensioni ha aiutato a raggiungere oggetti di memoria di picco più elevati. Grazie. Vi farò sapere la mia configurazione e alcuni dettagli degli oggetti che creiamo. E farà una domanda (nel prossimo commento). Il profiler indica 2 posti che consumano molta memoria: 1) Vengono create circa 5 stringhe (ciascuna 110 KB) al secondo. 2) Un oggetto contenente 4 oggetti (di una singola classe) viene creato uno al minuto e sostituito in una concurrenthashmap statica (quindi la mappa contiene solo 1 oggetto in qualsiasi momento). Ognuno di questi 4 oggetti contengono 10K ArrayLists, 10K Data e altre stringhe, ecc – prams

Problemi correlati