Elevata durata della Garbage Collection nei nodi del cluster Elasticsearch che causa picchi di latenza di ricerca

Ciao,

quello che descrivi è un comportamento piuttosto comune in cluster Elasticsearch sotto carico elevato: pause di Garbage Collection molto lunghe che si riflettono direttamente in picchi di latenza nelle query. La JVM heap è il punto critico, perché se troppo piccola porta a frequenti GC, mentre se troppo grande porta a pause più lunghe e a un peggior utilizzo della memoria fisica del nodo.

L’approccio consigliato è partire da una dimensione della heap proporzionata alla RAM del nodo, ma senza superare il limite di circa 30–32 GB. Questo perché oltre tale soglia la JVM perde l’ottimizzazione dei compressed oops, aumentando l’overhead. In ambienti Elasticsearch moderni, la best practice è assegnare circa il 50% della RAM disponibile al processo JVM, mantenendo l’altra metà per il filesystem cache, che è fondamentale per le performance di ricerca. Ad esempio, se il nodo ha 64 GB di RAM, la heap dovrebbe essere intorno ai 30–31 GB, lasciando il resto al sistema operativo.

Per ridurre l’impatto delle pause GC, è importante anche scegliere il garbage collector appropriato. Su versioni recenti di Elasticsearch (basate su JDK 11 e superiori), il G1GC è il default e offre un buon compromesso tra throughput e pause. Se le pause rimangono elevate, puoi intervenire con parametri di tuning come -XX:InitiatingHeapOccupancyPercent per anticipare la fase di concurrent GC, oppure monitorare con jstat e gli strumenti di Elastic (Monitoring / Hot Threads) per capire se il problema è legato a heap fragmentation o a query particolarmente pesanti.

Un altro aspetto è il bilanciamento del carico: se il cluster ha nodi con heap troppo sbilanciata rispetto al volume di shard, conviene ridistribuire gli indici e ridurre il numero di shard per nodo. Troppi shard piccoli portano overhead di gestione e più oggetti in heap, aumentando la pressione sul GC.

In sintesi, la strategia è: mantenere la heap sotto i 32 GB, allocare circa metà della RAM al processo JVM e metà al filesystem cache, usare G1GC con parametri di tuning mirati, e ridistribuire shard e indici per ridurre la pressione sulla heap. Questo riduce le pause di Garbage Collection senza compromettere la stabilità complessiva del cluster.

Domic Vo.