2008-12-05 20 views
18

Sto esplorando la possibilità di eseguire un'applicazione Java su una macchina con grandi quantità di RAM (ovunque da 300 GB a 15 TB, probabilmente su una macchina SGI Altix 4700) e I ' Sono curioso di sapere come è probabile che il GC di Java si esibisca in questo scenario.Prestazioni Java con grandi quantità di RAM

Ho sentito dire che le JVM di IBM o JRockit potrebbero essere più adatte a questo rispetto a quelle di Sun. Qualcuno sa di qualsiasi ricerca o dati sulle prestazioni della JVM in questa situazione?

risposta

6

sul Sole JVM, è possibile utilizzare l'opzione -XX: UseConcMarkSweepGC per accendere il marchio concorrente e spazzare collezionista, che eviterà quasi completamente le fasi di "fermare il mondo" dell'algoritmo GC predefinito, al costo di un po 'più di overhead.

Il consiglio di utilizzare più che su VM su una macchina del genere è IMHO obsoleto. Nelle applicazioni del mondo reale è spesso sufficiente disporre di dati condivisi in modo che le prestazioni con CMS e una JVM siano migliori.

+0

Ci sono molti validi motivi per utilizzare più JVM di questo e l'utilizzo di uno solo limiterà davvero la tua capacità di mantenere il tempo di attività, ma di cambiare i cicli e gestire i guasti. – cletus

+1

concordato. Ma la domanda riguardava "prestazioni" – kohlerm

-8

Sicuramente la risposta su come il GC sta per esibirsi è "a chi importa?" ;-)

+0

Heh, beh, ad esempio, sarebbe problematico se causasse il congelamento della macchina per diverse ore senza preavviso mentre faceva un GC completo. – sanity

+0

Sembra ovvio che l'autore della domanda se ne frega. Duh. – Guge

+1

Penso che Will abbia detto umoristicamente che "è improbabile che GC si verifichi". Questo è probabilmente vero per le cose che corro; nessun indizio sull'interrogante. :) – skiphoppy

4

La domanda è: si desidera eseguire all'interno di un singolo processo (JVM) o no? Se lo fai, avrai un problema. Fare riferimento a Tuning Java Virtual Machines, Oracle Coherence User Guide e documentazione simile. La regola empirica su cui ho operato è provare ad evitare cumuli più grandi di 1 GB. Considerando che un GC completo da 512 MB-1 GB potrebbe richiedere meno di un secondo. Un GC completo da 2-4 GB potrebbe richiedere potenzialmente 5 secondi o più. Ovviamente questo dipende da molti fattori, ma la morale della storia è che il sovraccarico di GC non si ridimensiona linearmente e una volta entrati nella prestazione di un secondo, si degrada rapidamente.

+0

Sicuramente GC è fatto in un thread separato, non è vero? –

+0

Paul, credo che la maggior parte dei GC avvenga in un thread separato, ma a volte è necessario un GC completo e blocca l'applicazione. Non sono al 100% però. – sanity

+0

Paul: Con Java 5, GC viene eseguito in un thread separato ma ci sono situazioni in cui deve spostare dati "speciali" (come lo stack). In questo caso, bloccherà la VM. Java 6 è migliore ma a volte blocca ancora. –

2

Questa non è affatto la risposta alla tua domanda, ma se pianifichi di distribuire un'enorme app Java potresti essere interessato a esaminare Azul Systems appliances. Dicono di essere in grado di raccogliere i rifiuti senza creare una pausa nell'applicazione fino a un singolo heap da 670 GB.

+0

Una differenza è che Azul è progettato per Java, non ha nemmeno un compilatore C! –

3

di Sun JVM consente di configurare e ottimizzare il heck fuori di raccolta dei rifiuti, ma è una scienza a sé: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html

Potrebbe essere necessario fare un po 'di lettura e di ricerca, ma per questo tipo di macchina, GC le impostazioni ottimizzate per la macchina e l'applicazione fanno probabilmente una grande differenza.

3

Da 5.0 Hotspot JVM utilizza un concetto noto come Ergonomia per cercare di ottimizzare l'utilizzo della memoria. Questo si basa su più della semplice quantità di memoria disponibile e su dimensioni di heap degli effetti, dimensioni di generazione e algoritmi di garbage collection.

Inizia da avere una lettura di questo, che spiega Ergonomia e di più:

http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf

C'è anche un ragazzo chiamato Brian Goetz che è scritto numerosi articoli su come Java alloca e utilizza la memoria, ognuno dei quali e più può essere trovato qui:

http://www.briangoetz.com/pubs.html

0

ci sono alcune risposte supplementari nelle risposte precedenti ad un similar question

0

Le uniche persone che possono veramente dire sei SGI. I computer super non si comportano come i server regolari solo più grandi.

Tuttavia, ho trovato che Java funziona meglio quando la memoria è locale ai processori che vi accedono. Nota: il GC deve essere in grado di percorrere l'intera memoria dall'inizio alla fine. Ciò significa che non si adatta bene se si dispone di un design che è come un sacco di computer bloccati insieme che potrebbe essere il caso qui. La dimensione del modulo di memoria è di 32 GB, pertanto è possibile ottenere prestazioni migliori se si limita la capacità della JVM di adattarsi a queste dimensioni.

1

Si consiglia di considerare l'esecuzione di un cluster virtuale Terracotta su questa macchina.

0

La risposta accettata per questo post è piuttosto vecchia ed è ormai obsoleta. A partire da settembre 2014, se stai usando Java 7, dovresti probabilmente passare al collector GC1. Dalle Java 7 Update 4 note di rilascio:.

http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html

"Il collezionista G1 è mirato per applicazioni che utilizzano appieno la grande quantità di memoria disponibile in server multiprocessore di oggi, pur mantenendo le latenze di raccolta dei rifiuti sotto controllo le applicazioni che richiedono un grande heap, hanno un grande data set attivo, hanno carichi di lavoro scomposti o non uniformi o soffrono di lunghe latenze indotte dalla Garbage Collection che dovrebbero trarre vantaggio dal passaggio a G1. "

Problemi correlati