Comprensione e Ottimizzazione della Dimensione dell'Heap JVM di Elasticsearch per le Prestazioni

La dimensione dell'heap JVM di Elasticsearch è una di quelle impostazioni che le persone spesso toccano troppo presto e poi incolpano troppo tardi. Un cluster lento non ha sempre bisogno di più heap. A volte è vero il contrario: l'heap è abbastanza grande, ma il sistema operativo ha troppa poca memoria rimasta per la cache del filesystem, quindi Lucene deve tornare più spesso al disco. Altre volte l'heap è genuinamente troppo piccolo, la garbage collection è in esecuzione costante e ogni ricerca sembra come camminare nel cemento bagnato.

L'obiettivo pratico non è trovare un numero magico. L'obiettivo è dare a Elasticsearch abbastanza heap per i metadati del cluster, i buffer di indicizzazione, le aggregazioni, il lavoro di query e le cache, lasciando abbastanza RAM al di fuori dell'heap per i file dei segmenti di Lucene e il sistema operativo. Se ricordi solo una cosa, ricorda che le prestazioni di Elasticsearch dipendono sia dalla memoria heap che da quella off-heap.

Inizia separando due tipi di pressione sulla memoria. La pressione dell'heap JVM si manifesta con un'alta percentuale di heap, lunghe pause di garbage collection, eccezioni del circuit breaker genitore, pressione fielddata o OutOfMemoryError. La pressione off-heap di solito si presenta come ricerche lente anche se l'heap sembra a posto, elevate letture del disco, attività di swap o scarsi tassi di hit della cache dopo un riavvio. Aumentare l'heap può aiutare il primo caso. Può peggiorare il secondo caso.

Per la maggior parte dei cluster auto-gestiti, la vecchia regola empirica funziona ancora come punto di partenza: imposta l'heap a non più della metà della RAM della macchina e mantienilo al di sotto della soglia dei puntatori a oggetti compressi. Le persone spesso citano quella soglia come "circa 32 GB". In pratica, molti operatori si mantengono intorno ai 26-31 GB perché il cutoff esatto dipende dalla JVM e dal layout runtime. Elasticsearch registra se i puntatori a oggetti compressi sono abilitati all'avvio. Considera il log di avvio come la fonte di verità per il tuo nodo.

Nelle versioni moderne di Elasticsearch, il dimensionamento automatico dell'heap potrebbe già impostare un valore ragionevole basato sui ruoli del nodo e sulla memoria disponibile. Questo è utile, specialmente per cluster più piccoli e distribuzioni standard. La regolazione manuale conta ancora quando un nodo ha un carico di lavoro insolito: aggregazioni pesanti, mapping grandi, molti shard, pipeline di ingest, job di trasformazione, ruoli di machine learning o un mix di ricerca calda e alto volume di indicizzazione.

Ecco un semplice esempio. Supponiamo di avere un nodo dati caldo da 64 GB che gestisce sia l'indicizzazione che la ricerca. Un heap di 30 GB è un punto di partenza comune. Lascia circa metà della RAM per la cache di pagina del sistema operativo e la memoria nativa. Se lo stesso nodo fa parte di un cluster di logging con molti shard piccoli e aggregazioni ad alta cardinalità, potresti ancora vedere pressione sull'heap. La soluzione potrebbe essere una migliore progettazione degli shard o una pulizia del mapping, non automaticamente un heap da 40 GB. Superare la soglia dei puntatori compressi può aumentare la dimensione del puntatore a oggetti e ridurre l'efficienza effettiva dell'heap.

Imposta l'heap minimo e massimo allo stesso valore. Elasticsearch non dovrebbe passare tempo a ridimensionare l'heap mentre serve traffico.

-Xms30g
-Xmx30g

Usa un file sotto jvm.options.d/ piuttosto che modificare direttamente il file jvm.options confezionato quando la tua installazione lo supporta. Per le installazioni tramite pacchetto, di solito significa qualcosa come /etc/elasticsearch/jvm.options.d/heap.options. Per Docker, passa le impostazioni dell'heap attraverso la variabile d'ambiente supportata o la configurazione montata. Mantieni l'impostazione coerente per i nodi con lo stesso ruolo, ma non presumere che ogni ruolo abbia bisogno dello stesso heap. I nodi dedicati eleggibili come master spesso hanno bisogno di molto meno heap dei nodi dati occupati, a meno che il cluster non abbia metadati molto grandi a causa di troppi indici, campi o shard.

Prima di cambiare l'heap, fai un'istantanea del comportamento attuale. Guarda le statistiche JVM:

GET _nodes/stats/jvm?filter_path=nodes.*.jvm.mem,nodes.*.jvm.gc

Poi controlla i breaker e fielddata:

GET _nodes/stats/breaker,indices/fielddata?pretty

Controlla anche shard e mapping. Un cluster con migliaia di shard minuscoli può bruciare heap in overhead anche quando il volume di dati non è enorme.

GET _cat/shards?v&bytes=gb
GET _cluster/stats?filter_path=indices.count,indices.shards,indices.mappings

I sintomi contano più del numero headline. L'heap che si aggira intorno al 70-85% durante i picchi può essere normale se la garbage collection lo riduce rapidamente. L'heap che sale al 90% e oltre e rimane lì è diverso. Le lunghe pause di GC della vecchia generazione sono peggiori di una percentuale alta di per sé. Se le ricerche vanno in timeout ogni volta che la GC viene eseguita, agli utenti non importa che il grafico medio dell'heap sembrasse accettabile.

Un errore comune in produzione è usare l'heap come cerotto per mapping scadenti. Ordinare o aggregare su campi text analizzati con fielddata: true può consumare molto heap. La soluzione migliore è di solito un sottocampo keyword, un campo a cardinalità inferiore o un design di aggregazione diverso. Un altro errore è permettere ai mapping dinamici di creare migliaia di campi da chiavi JSON arbitrarie. L'heap poi scompare in mapping, stato del cluster e strutture di query. Metti dei confini attorno ai campi dinamici prima che diventino un problema operativo.

Le aggregazioni meritano un'attenzione speciale. Un'aggregazione terms su un campo ad alta cardinalità può creare grandi strutture in memoria. Se qualcuno esegue una dashboard che raggruppa per user_id, session_id o URL completo su un lungo intervallo di tempo, la pressione sull'heap può aumentare anche se le ricerche ordinarie sembrano a posto. Usa finestre temporali più piccole, filtri che restringono il set di lavoro, aggregazioni composite per la paginazione o rollup pre-aggregati dove appropriato. Aumentare l'heap può ritardare il fallimento, ma non renderà un'aggregazione illimitata economica.

L'indicizzazione ha il suo schema di heap. Le richieste bulk creano pressione transitoria. Payload bulk molto grandi possono forzare Elasticsearch a trattenere troppo lavoro contemporaneamente. Se vedi rifiuti di indicizzazione o picchi di heap durante l'ingestione, prova batch bulk più piccoli e più controllo della concorrenza lato client. Un intervallo di partenza utile è spesso pochi megabyte per richiesta bulk, poi testa verso l'alto con i tuoi documenti reali. Il valore giusto dipende dalla dimensione del documento, dalle pipeline di ingest, dalle repliche, dall'intervallo di refresh e dalla velocità di archiviazione.

Non ignorare il sistema operativo. Disabilita lo swap o configura l'host in modo che la memoria di Elasticsearch non venga scambiata. Lo swapping può trasformare un problema di memoria recuperabile in un lungo blocco perché le pause JVM diventano enormi. Assicurati che il processo abbia il permesso di bloccare la memoria se usi bootstrap.memory_lock: true, e verificalo all'avvio piuttosto che presumere che l'impostazione abbia funzionato.

Dopo aver cambiato l'heap, riavvia un nodo alla volta in un cluster di produzione e attendi che il recupero degli shard si stabilizzi prima di passare al nodo successivo. Osserva la latenza di ricerca, le pause GC, le letture del disco e il throughput di indicizzazione per almeno un ciclo di traffico normale. Un cambiamento che sembra buono durante un'ora tranquilla potrebbe fallire durante il picco mattutino della dashboard.

Se un nodo continua a subire pressione sull'heap dopo una regolazione sensata, fai un passo indietro e chiediti cosa sta trattenendo l'heap. Troppi shard, troppi campi, fielddata su text, aggregazioni sovradimensionate, script pesanti e ruoli misti sullo stesso nodo sono cause più comuni di "Elasticsearch ha bisogno di tutta la RAM". Il lavoro più forte di regolazione dell'heap spesso termina con un mapping più piccolo, meno shard, limiti di query migliori o un tier di ingest dedicato.

La regolazione dell'heap non è una cerimonia una tantum. Fa parte della gestione della capacità. Quando il volume dei dati cresce, le dashboard cambiano o un nuovo team inizia a inviare documenti più ampi, anche il profilo di memoria cambia. Mantieni il dimensionamento dell'heap noioso: misura, cambia una cosa, riavvia in sicurezza e verifica con dati di carico di lavoro reali.