Scalatura verticale dell'applicazione Java real-time

Question

Con l'ottimizzazione GC riesco a ottenere prestazioni per applicazioni java in tempo reale ed evitare pause riconoscibili del GC. Ma ciò vale fino a ~ 20 GB di spazio heap.

La riduzione del costo dell'hardware ha reso accessibili anche 100 GB di RAM. Ma, ancora con Java a causa delle pause di GC, dimensioni di heap più elevate come 50 GB possono mandarti in incubo a intervalli regolari.

Capisco che ci siano opzioni come off-heap e heap distribuito. Tuttavia, off-heap ha uno svantaggio di se/derializzazione e l'heap distribuito sulla mano aumenta i costi di manutenzione. Inoltre, nell'heap distribuito in realtà non si utilizza completamente la RAM (ad esempio 64 GB) che in questi giorni sta diventando comune come commodity.

Pertanto, per sfruttare appieno il potenziale della RAM, quali sono le buone soluzioni per il ridimensionamento verticale delle applicazioni Java?

Answer 1

Sto lavorando a una libreria di raccolte primitive denominata Banana. Banana si rivolge a quegli esatti problemi. Supporta LinkedLists, HashMaps e possibilmente altre strutture di dati presto senza il sovraccarico di mantenere N oggetti. in pratica - l'intera memoria può trovarsi all'interno di un array [] (o molti) int.

Anche se non l'ho ancora rilasciato ufficialmente, la maggior parte è ben testata e l'ho già eseguita con successo su server con 144 GB di RAM, mantenendo prestazioni veloci e costanti senza alcuna pausa GC.

Check out this benchmark hash-map per avere un'idea su come utilizzare Banana per archiviare i dati e come si scala in verticale.

https://github.com/omry/banana/wiki/Long-to-fixed-size-object-benchmark

Vedere la wiki per maggiori informazioni.

Answer 2

Il tempo di raccolta dei dati inutili è una funzione del numero di oggetti attivi nell'heap. Ciò significa che se il tuo tasso di allocazione è molto alto ma il numero di oggetti live è sempre basso, puoi utilizzare tutta la RAM che vuoi senza avere pause significative.

Questa affermazione è particolarmente valida per il raccoglitore Troughput (-XX:+UseParallelOldGC).

Se si utilizza CMS, probabilmente si desidera verificarne la modalità incrementale (-XX:+CMSIncrementalMode). Attiverà cicli CMS più piccoli per pulire una frazione più piccola del tuo heap, sfruttando al contempo l'hardware e senza pause STW.

Se CMS non è un'opzione, è necessario dare un'occhiata a G1 (-XX:+UseG1GC), che è un nuovo Garbage Collector progettato per heap di grandi dimensioni. Il principio è: pulire solo diverse regioni dell'heap ad ogni ciclo, ma assicurati che queste regioni contengano molti oggetti morti (guadagni rapidi).

Spero che questo aiuti!

Fonti:

• http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
• http://jvm-options.tech.xebia.fr/

Answer 3

ho fatto qualche ricerca su scala dimensione heap di JVM. Puoi leggere maggiori dettagli here e here.

Conclusione principale: la pausa GC giovane ha due componenti costanti e variabili.

Il componente costante dipende dalle dimensioni del vecchio spazio e per 64GiB, mi aspetto che sia 80ms-120ms (dipende dall'hardware).

La componente variabile dipende dalla sopravvivenza degli oggetti nello spazio giovane (quindi passa dalla raccolta alla raccolta). È veramente specifico per l'applicazione, ma di solito è possibile ridurlo riducendo lo spazio giovane (al costo di pause più frequenti).

Nel tuo caso per 4 GiB di spazio giovane hai 500ms. Supponendo che il componente variabile sia 400ms, se riduci lo spazio giovane a 1 GiB dovresti avere pause di ~ 200 ms (ma 2 volte al secondo).

Un altro approccio consiste nell'utilizzare più core CPU, GC giovani paralleli extremely well.

Answer 4

I garbage collector G1 e Shenandoah (sperimentali) offrono una grande elasticità e sbloccano il ridimensionamento verticale per le applicazioni Java ottimizzando l'utilizzo della memoria in base al carico corrente. Ulteriori specifiche come funziona sono al l'articolo Minimize Java Memory Usage with the Right Garbage Collector