Risoluzione dei Colli di Bottiglia Comuni nelle Prestazioni di Elasticsearch

La risoluzione dei colli di bottiglia nelle prestazioni di Elasticsearch funziona meglio quando si resiste alla prima teoria facile. Una dashboard lenta potrebbe essere una query errata, ma potrebbe anche essere uno shard caldo, un disco saturo, un problema di heap, un errore di mapping o un processo di recupero che compete per I/O. Inizia con le prove, poi restringi il campo.

Di solito divido la domanda in tre parti: cosa è lento, dove è lento e cosa è cambiato. "Elasticsearch è lento" non è un'informazione utilizzabile. "La latenza di ricerca per logs-prod-* è raddoppiata dopo la modifica del mapping di ieri, principalmente su due nodi dati" ti dà un punto da cui partire.

Diagnosi dei Problemi di Prestazioni

Prima di immergerci in soluzioni specifiche, è essenziale disporre di strumenti e metodi per diagnosticare i problemi di prestazioni. Elasticsearch fornisce diverse API e metriche che sono preziose per questo processo.

Strumenti e Metriche Chiave:

• API Cluster Health (_cluster/health): Fornisce una panoramica dello stato del cluster (verde, giallo, rosso), numero di nodi, shard e attività in sospeso. Un numero elevato di attività in sospeso può indicare problemi di indicizzazione o recupero.
• API Node Stats (_nodes/stats): Offre statistiche dettagliate per ogni nodo, inclusi utilizzo CPU, memoria, I/O disco, traffico di rete e utilizzo heap JVM. Questo è fondamentale per identificare i nodi con risorse limitate.
• API Index Stats (_stats): Fornisce statistiche per singoli indici, come tassi di indicizzazione, tassi di ricerca e utilizzo della cache. Questo aiuta a individuare indici problematici.
• Slow Log: Elasticsearch può registrare richieste di indicizzazione e ricerca lente. Le soglie dei slow log sono impostazioni dell'indice, quindi puoi applicarle a un indice rumoroso invece di trasformare l'intero cluster in un generatore di log.
  • Indexing Slow Log: Utile quando le scritture bulk si bloccano o la latenza di ingest salta.
  • Search Slow Log: Utile quando hai bisogno del modello di richiesta effettivo, non solo di un grafico di latenza.
• Strumenti di Monitoraggio: Soluzioni come l'interfaccia di monitoraggio di Kibana, Prometheus con Elasticsearch Exporter o strumenti APM commerciali forniscono dashboard e dati storici per un'analisi più approfondita.

Colli di Bottiglia Comuni e Soluzioni

1. Indicizzazione Lenta

L'indicizzazione lenta può essere causata da vari fattori, tra cui latenza di rete, colli di bottiglia I/O del disco, risorse insufficienti, mapping inefficiente o utilizzo non ottimale dell'API Bulk.

Cause e Soluzioni:

• Saturazione I/O Disco: Elasticsearch dipende fortemente da un I/O disco veloce per l'indicizzazione. Gli SSD sono altamente raccomandati.

  • Diagnosi: Monitora IOPS di lettura/scrittura e throughput utilizzando _nodes/stats o strumenti a livello di sistema operativo. Cerca profondità di coda elevate.
  • Soluzione: Aggiorna a uno storage più veloce (SSD), distribuisci gli shard su più nodi o ottimizza la tua strategia di shard per ridurre l'I/O per nodo.

• Pressione Heap JVM: Se l'heap JVM è costantemente sotto pressione, la garbage collection può diventare un collo di bottiglia significativo, rallentando tutte le operazioni, inclusa l'indicizzazione.

  • Diagnosi: Monitora l'utilizzo dell'heap JVM in Kibana Monitoring o _nodes/stats. Un utilizzo elevato dell'heap e pause di garbage collection frequenti e lunghe sono bandiere rosse.
  • Soluzione: Aumenta la dimensione dell'heap JVM (ma non oltre il 50% della RAM di sistema e non superiore a 30,5 GB), ottimizza i mapping per ridurre la dimensione dei documenti o aggiungi più nodi per distribuire il carico.

• Mapping Inefficiente: Mapping eccessivamente complessi, mapping dinamico con molti nuovi campi creati o tipi di dati errati possono aumentare il sovraccarico di indicizzazione.

  • Diagnosi: Analizza i mapping degli indici (API _mapping). Cerca oggetti nidificati, un gran numero di campi o campi indicizzati inutilmente.
  • Soluzione: Definisci mapping espliciti con tipi di dati appropriati. Usa dynamic: false o dynamic: strict dove applicabile. Evita strutture profondamente nidificate se non essenziali.

• Latenza di Rete: Un'elevata latenza tra nodi o tra client e cluster può rallentare le richieste di indicizzazione bulk.

  • Diagnosi: Misura la latenza di rete tra i tuoi client/nodi. Analizza i tempi di risposta dell'API Bulk.
  • Soluzione: Mantieni i nodi del cluster su una rete privata a bassa latenza, posiziona i client bulk vicino al cluster quando possibile e riduci il traffico cross-regione non necessario. Le impostazioni della cache delle richieste non risolveranno la latenza di rete.

• Utilizzo Non Ottimale dell'API Bulk: Inviare richieste individuali invece di utilizzare richieste bulk, o inviare richieste bulk eccessivamente grandi/piccole, può essere inefficiente.

  • Diagnosi: Monitora il throughput della tua indicizzazione bulk. Analizza la dimensione delle tue richieste bulk.
  • Soluzione: Usa l'API Bulk per tutte le operazioni di indicizzazione. Sperimenta con la dimensione del bulk (in genere 5-15 MB per richiesta bulk è un buon punto di partenza) per trovare l'equilibrio ottimale tra throughput e latenza. Assicurati che le tue richieste bulk siano adeguatamente raggruppate.

• Durabilità del Translog: L'impostazione index.translog.durability controlla la frequenza con cui il log delle transazioni viene scaricato su disco. request (predefinito) è più sicuro ma può influire sulle prestazioni rispetto a async.

  • Diagnosi: Questa è un'impostazione di configurazione.
  • Soluzione: Per il massimo throughput di indicizzazione, considera la durabilità async. Tuttavia, tieni presente che ciò aumenta il rischio di perdita di dati in caso di crash del nodo tra uno scaricamento e l'altro.

2. Query Lente

Le prestazioni delle query sono influenzate dalla dimensione dello shard, dalla complessità della query, dalla memorizzazione nella cache e dall'efficienza della struttura dati sottostante.

Cause e Soluzioni:

• Shard Grandi: Shard troppo grandi possono rallentare le query poiché Elasticsearch deve cercare attraverso più dati e unire i risultati da più segmenti.

  • Diagnosi: Controlla le dimensioni degli shard utilizzando _cat/shards o _all/settings?pretty.
  • Soluzione: Punta a dimensioni degli shard comprese tra 10 GB e 50 GB. Considera la reindicizzazione dei dati in un nuovo indice con shard più piccoli o l'utilizzo di Index Lifecycle Management (ILM) per gestire la dimensione degli shard nel tempo.

• Troppi Shard: Avere un numero eccessivo di shard piccoli può portare a un elevato sovraccarico per il cluster, specialmente durante le ricerche. Ogni shard richiede risorse per la gestione.

  • Diagnosi: Conta il numero totale di shard per nodo e per indice utilizzando _cat/shards.
  • Soluzione: Consolida gli indici se possibile. Ottimizza il tuo modello di dati per ridurre il numero di indici e quindi il numero totale di shard. Per i dati di serie temporali, ILM può aiutare a gestire il conteggio degli shard.

• Query Inefficienti: Query complesse, query che coinvolgono scripting pesante, ricerche con caratteri jolly all'inizio dei termini o espressioni regolari possono essere molto intensive in termini di risorse.

  • Diagnosi: Usa l'API Profile (_search?profile=true) per analizzare il tempo di esecuzione della query e identificare le parti lente. Analizza i slow log.
  • Soluzione: Semplifica le query. Evita caratteri jolly iniziali e regex costose. Usa query term invece di match per corrispondenze esatte quando possibile. Considera l'utilizzo di suggeritori search_as_you_type o completion per suggerimenti di digitazione. Ottimizza le clausole di filtro (usa il contesto filter invece del contesto query per query non di punteggio).

• Mancanza di Caching: Una memorizzazione nella cache insufficiente o inefficace può portare a calcoli e recuperi di dati ripetuti.

  • Diagnosi: Monitora i tassi di hit della cache per la cache delle query e la cache delle richieste utilizzando _nodes/stats/indices/query_cache e _nodes/stats/indices/request_cache.
  • Soluzione: Assicurati che il caching appropriato sia abilitato. La cache dei filtri (parte della cache delle query) è particolarmente importante per query di filtro ripetute. Per query identiche eseguite frequentemente, considera l'abilitazione della cache delle richieste.

• Sovraccarico di Unione dei Segmenti: Elasticsearch unisce i segmenti più piccoli in quelli più grandi in background. Questo processo consuma risorse I/O e CPU, che a volte possono influire sulle prestazioni delle query in tempo reale.

  • Diagnosi: Monitora il numero di segmenti per shard utilizzando _cat/segments.
  • Soluzione: Evita di modificare le impostazioni di unione con noncuranza. Durante un grande backfill, riduci la frequenza di refresh, controlla la concorrenza bulk e osserva la limitazione dell'unione e l'I/O del disco. I force merge sono solitamente per indici di sola lettura, non per indici hot attivi.

3. Contesa di Risorse (CPU, Memoria, Rete)

La contesa di risorse è una categoria ampia che può manifestarsi sia nel degrado delle prestazioni di indicizzazione che di query.

Cause e Soluzioni:

• Sovraccarico CPU: Un utilizzo elevato della CPU può essere causato da query complesse, aggregazioni intensive, troppe operazioni di indicizzazione o garbage collection eccessiva.

  • Diagnosi: Monitora l'utilizzo della CPU per nodo (_nodes/stats). Identifica quali operazioni consumano più CPU (es. ricerca, indicizzazione, JVM GC).
  • Soluzione: Ottimizza query e aggregazioni. Distribuisci il carico su più nodi. Riduci il tasso di indicizzazione se sta sovraccaricando la CPU. Assicurati impostazioni adeguate dell'heap JVM per ridurre al minimo il sovraccarico di GC.

• Problemi di Memoria (Heap JVM e Memoria di Sistema): Un heap JVM insufficiente porta a GC frequenti. L'esaurimento della memoria di sistema può causare swapping, riducendo drasticamente le prestazioni.

  • Diagnosi: Monitora l'utilizzo dell'heap JVM e la memoria di sistema complessiva (RAM, swap) su ogni nodo.
  • Soluzione: Alloca heap JVM sufficiente (es. 50% della RAM di sistema, fino a 30,5 GB). Evita lo swapping assicurando sufficiente memoria di sistema libera. Considera l'aggiunta di più nodi o l'utilizzo di nodi dedicati per ruoli specifici (master, dati, ingest).

• Colli di Bottiglia di Rete: Un traffico di rete elevato può rallentare la comunicazione tra nodi, la replica e le richieste dei client.

  • Diagnosi: Monitora l'utilizzo della larghezza di banda di rete e la latenza tra nodi e client.
  • Soluzione: Ottimizza l'infrastruttura di rete. Riduci il trasferimento di dati non necessario. Assicurati impostazioni ottimali di allocazione e replica degli shard.

• Saturazione I/O Disco: Come menzionato nell'indicizzazione, questo influisce anche sulle prestazioni delle query durante la lettura dei dati dal disco.

  • Diagnosi: Monitora le metriche I/O del disco.
  • Soluzione: Aggiorna a uno storage più veloce, distribuisci i dati su più nodi o ottimizza le query per ridurre la quantità di dati letti.

Best Practice per l'Ottimizzazione delle Prestazioni

• Monitora Continuamente: L'ottimizzazione delle prestazioni è un processo continuo. Monitora regolarmente la salute del tuo cluster e l'utilizzo delle risorse.
• Ottimizza i Mapping: Definisci mapping espliciti ed efficienti su misura per i tuoi dati. Evita campi o indicizzazioni non necessari.
• Strategia degli Shard: Punta a dimensioni ottimali degli shard (10-50 GB) ed evita di avere troppi o troppo pochi shard.
• Usa l'API Bulk: Usa l'API Bulk per l'indicizzazione e l'API multi-search quando devi raggruppare ricerche indipendenti.
• Ottimizza l'Heap JVM: Alloca heap sufficiente, ma non sovra-allocare. Evita lo swapping.
• Comprendi le Prestazioni delle Query: Profila le query, semplificale e sfrutta il contesto del filtro.
• Sfrutta il Caching: Assicurati che le cache delle query e delle richieste siano utilizzate efficacemente.
• Hardware: Usa SSD per lo storage e assicura CPU e RAM adeguate.
• Nodi Dedicati: Considera l'utilizzo di nodi dedicati per i ruoli master, dati e ingest per isolare i carichi di lavoro.
• Index Lifecycle Management (ILM): Per i dati di serie temporali, ILM è essenziale per gestire gli indici, eseguire il rollover degli shard ed eliminare infine i vecchi dati, il che aiuta a controllare il numero e la dimensione degli shard.

Quando trovi un collo di bottiglia, apporta la modifica più piccola che lo affronti direttamente. Aggiungi nodi quando il cluster è genuinamente a corto di capacità. Correggi i mapping quando l'heap viene sprecato. Riscrivi le query quando l'output del profilo punta a clausole costose. Regola la strategia degli shard quando un nodo sta facendo un lavoro che dovrebbe essere distribuito. Questa disciplina impedisce che il lavoro sulle prestazioni diventi un mucchio di manopole di ottimizzazione non correlate.