Ottimizzare la dimensione dell'heap della JVM in Kubernetes

Stimare la dimensione delle risorse a disposizione di un Pod può non essere un compito semplice, soprattutto se c’è di mezzo la JVM… Vediamo alcune best practices e considerazioni da tenere a mente!

In genere non è una buona pratica impostare l’intera dimensione della memoria allocata del pod come dimensione massima dell’heap (-Xmx) per le applicazioni Java. Questo può portare a errori di Out-of-memory (OOM) o a crash del pod, soprattutto in ambienti Kubernetes. Ecco perché!

Alcune considerazioni

Partiamo da alcuni punti di riflessione su come la memoria viene gestita per heap e non-heap. L’heap è necessario per la Java Virtual Machine, la quale utilizza l’heap come area di allocazione dinamica per gli oggetti Java e le istanze di classe durante l’esecuzione.

Invece, la memoria definita “non-heap” è la memoria che la JVM alloca per risorse…

Cosa succede se si alloca tutta la memoria a disposizione per l’heap?

Il primo effetto sarebbe un overhead di memoria per l’uso non-heap: La memoria della JVM è costituita da diversi componenti oltre all’heap (che -Xmx controlla). Questi includono:

• Metaspace (per i metadati delle classi e la memoria nativa).
• Stack dei thread (ogni thread ha il proprio stack).
• Garbage Collection overhead (memoria utilizzata durante le operazioni di GC).
• Memoria off-heap (utilizzata dal codice nativo o da librerie esterne).
• Strutture dati interne alla JVM (ad esempio, compilatore JIT, cache del codice).

Se si alloca il 100% della memoria del pod nell’heap utilizzando opzioni come -Xmx, non ci sarà spazio per questi altri componenti, il che può causare il superamento del limite di memoria del pod e la sua terminazione.

Altro effetto è l’overhead del sistema operativo: una parte della memoria a disposizione della risorsa applicativa è utilizzata anche dal runtime del container, come Docker o Kubernetes, e dal sistema operativo in esecuzione all’interno del container. Questo overhead deve essere tenuto in considerazione e l’allocazione di tutta la memoria nell’heap della JVM (-Xmx) può causare un sovraccarico di memoria.

Ultimo, ma non ultimo, è da considera che l’impostazione di -Xmx al massimo della memoria disponibile può portare ad avere delle dimensioni dell’heap molto grandi. Sebbene un heap di grandi dimensioni possa ridurre la frequenza della garbage collection, quando questa si verifica, può richiedere più tempo (soprattutto nel caso del Full GC), il che può portare ad un calo delle prestazioni o a rallentamenti dell’applicazione.

Cosa fare

Invece di assegnare l’intera memoria del pod all’heap della JVM, è prassi comune allocare una parte della memoria del pod all’heap della JVM e lasciare un po’ di spazio per la memoria non-heap e l’overhead del sistema operativo.

Quali sono delle linee guida generali per il dimensionamento dell’heap della JVM in Kubernetes?

Una regola empirica tipica è quella di allocare il 50%-70% della memoria totale del pod nell’heap della JVM utilizzando il parametro -Xmx. Ad esempio, se un pod ha 4 GB di memoria, si può impostare da “-Xmx2g” a “-Xmx3g” (da 2 a 3 GB per l’heap) per lasciare spazio all’utilizzo della memoria non-heap.

Non solo: è importante valutare una messa a punto del garbage collector: regolare il Garbage Collector e le sue configurazioni in base al comportamento della memoria dell’applicazione diventa fondamentale. Ad esempio: G1 è una buona scelta per la maggior parte delle applicazioni moderne, in quanto bilancia il throughput e i tempi di pausa durante le attività di garbage collection. Inoltre, ZGC o Shenandoah GC (introdotti nelle versioni più recenti della JVM) sono disponibili se si necessita di una garbage collection a bassa latenza in ambienti con heap di grandi dimensioni.

Esempio

Se si dispone di uno spazio con 4 GB di memoria totale, si consiglia di impostare -Xmx al massimo a 2.5 GB (-Xmx2560m), meglio se 2 GB, così che si lasci spazio ad altre aree di memoria della JVM e al sistema operativo.

Di conseguenza, sarà necessario impostare il limite di memoria in Kubernetes a 4 GB, ma tenere presente che l’utilizzo effettivo della memoria supererà la dimensione dell’heap.

resources:
  requests:
    memory: "2Gi"
  limits:
    memory: "4Gi"

Se si osservano frequenti errori OOM o pause GC eccessive, regolare la dimensione dell’heap di conseguenza.

Conclusione

Le best practices indicate che prevedono un’allocazione tipica del 50-70% della memoria del pod per l’heap della JVM, lasciando il resto per l’uso della memoria nativa e l’overhead del sistema operativo, sono raccomandazioni che servono a fornire una solida base per configurare efficacemente le dimensioni dell’heap JVM, assicurando prestazioni ottimali ed evitando potenziali problemi correlati alla memoria. Rimane comunque importante anche il monitoraggio e una revisione regolare di questi parametri in base alle richieste dell’applicazione, questo per mantenerne l’efficienza.