Come posso risolvere il problema dei picchi di latenza di ricerca nel mio cluster del Servizio OpenSearch di Amazon?

Breve descrizione

Per le richieste di ricerca, il Servizio OpenSearch calcola il tempo di andata e ritorno con la seguente formula:

Andata e ritorno = Tempo trascorso dalla query nella fase di interrogazione + Tempo nella fase di recupero + Tempo in coda + Latenza di rete

La metrica SearchLatency del Servizio OpenSearch in Amazon CloudWatch mostra il tempo impiegato dalla query nella fase di interrogazione.

Per risolvere i picchi di latenza di ricerca in un cluster del Servizio OpenSearch, intraprendi le seguenti azioni:

• Controlla le metriche dell'infrastruttura, come l'utilizzo della CPU, l'utilizzo del disco e la memoria sia per la pressione della memoria Java Virtual Machine (JVM) che per la rimozione di oggetti inutili (garbage collection).
• Verifica la presenza di picchi nella metrica SearchRate.
• Utilizza la metrica ThreadpoolSearchRejected per verificare la presenza di ricerche rifiutate.
• Utilizza i log delle query lente per identificare le query di lunga durata.
• Risolvi gli errori "504 gateway timeout".
• Ottimizza la configurazione per ridurre la latenza.

Risoluzione

Verifica le metriche dell'infrastruttura

La rimozione frequente e prolungata di oggetti inutili (garbage collection) dai nodi di dati del sistema operativo si verifica quando l'utilizzo delle risorse è elevato. Se non fornisci risorse sufficienti al cluster, potresti riscontrare picchi di latenza di ricerca.

Risolvi i problemi relativi all'utilizzo elevato delle risorse

Assicurati che le metriche CPUUtilization e JVMMemoryPressure per il cluster siano inferiori all'80%. Se i valori delle metriche in CloudWatch sono superiori all'80%, risolvi i problemi relativi all'utilizzo elevato della CPU o alla pressione elevata della memoria JVM.

Per monitorare in modo proattivo l'utilizzo delle risorse, configura allarmi in CloudWatch per il Servizio OpenSearch.

Per ottenere statistiche a livello di nodo sul cluster, esegui questa query più volte a intervalli di 5 minuti:

GET /_nodes/stats

Nell'output, cerca modifiche significative nell'utilizzo della cache, nella memoria fielddata e nei valori heap JVM tra le esecuzioni. Valori coerenti indicano un normale funzionamento. In caso di problemi potrebbero verificarsi picchi o cali improvvisi.

Controlla le impostazioni della cache

Il Servizio OpenSearch utilizza più cache per migliorare le prestazioni e il tempo di risposta delle richieste:

• Cache del file system, o cache delle pagine, a livello di sistema operativo
• Cache delle richieste a livello di shard e la cache delle query, entrambe a livello di Servizio OpenSearch

Per visualizzare le informazioni sulla cache del file system, esegui questa query:

GET /_nodes/stats/indices/request_cache?human

Per visualizzare le informazioni su una cache delle richieste a livello di shard, esegui questa query:

GET /_nodes/stats/indices/query_cache?human

Nell'output, controlla le espulsioni della cache. Un numero elevato di espulsioni della cache significa che la cache è troppo piccola per soddisfare la richiesta. Per ridurre le espulsioni, utilizza nodi più grandi con più memoria. Per ulteriori informazioni sui prezzi delle dimensioni dei nodi, consulta Prezzi del Servizio OpenSearch di Amazon. Per ulteriori informazioni sulle cache di OpenSearch, consulta Elasticsearch caching deep dive: Boosting query speed one cache at a time (Approfondimento sul caching di Elasticsearch: aumenta la velocità delle query una cache alla volta) sul sito web Elastic.

Per svuotare la cache, consulta Clear cache API (API clear cache) sul sito web OpenSearch.

Le aggregazioni su campi che contengono valori altamente univoci potrebbero causare un aumento dell'utilizzo dell'heap. Le operazioni di ricerca per le query di aggregazione utilizzano fielddata. I fielddata ordinano e accedono anche ai valori dei campi nello script. Le espulsioni di fielddata dipendono dalla dimensione del file indices.fielddata.cache.size, che rappresenta il 20% dello spazio dell'heap JVM.

Per verificare la quantità di memoria utilizzata dai fielddata in tutti i nodi del cluster, esegui questa query:

GET /_nodes/stats/indices/fielddata?human

Verifica la presenza di picchi nella metrica SearchRate

Più richieste di ricerca in un breve lasso di tempo possono sovraccaricare le risorse di un cluster e causare ritardi nell'elaborazione delle query e tempi di risposta più lenti per le singole ricerche. Una frequenza elevata di ricerche nel Servizio OpenSearch può causare una maggiore latenza di ricerca. Se la metrica SearchRate aumenta, controlla se i picchi si verificano contemporaneamente ai picchi di latenza di ricerca. Se i picchi si verificano contemporaneamente, devi aggiungere più risorse al cluster o ottimizzare le query per gestire il carico di ricerca.

Verifica la presenza di ricerche rifiutate

Utilizza la metrica ThreadpoolSearchRejected per identificare e risolvere i problemi di ricerche rifiutate.

Utilizza i log delle query lente per identificare le query di lunga durata

Per identificare le query di lunga durata e il tempo trascorso da una query in uno shard specifico, utilizza i log delle query lente. Puoi impostare soglie per la fase di query e recuperare la fase per ogni indice.

Per un riepilogo dettagliato del tempo trascorso dalla query nella fase di ricerca, imposta profile su true nella query di ricerca.

Esempio di query:

GET /my_index/_search
{
  "profile": true,
  "query": {
    "match": {
      "field": "value"
    }
  }
}

Nota: se imposti la soglia di registrazione su un valore troppo basso, la pressione della memoria JVM e la latenza del cluster potrebbero aumentare. Quando registri più query, aumenti anche i costi. Un output di grandi dimensioni per una query con profile impostato su true aggiunge un sovraccarico alle altre query di ricerca. Di conseguenza, le altre ricerche subiscono un temporaneo rallentamento.

Risolvi gli errori "504 gateway timeout"

Prerequisito: attiva i log degli errori per identificare codici di errore HTTP specifici.

Utilizza i log delle applicazioni del cluster del Servizio OpenSearch per controllare codici di errore HTTP specifici per le singole richieste. Per risolvere gli errori HTTP 504 gateway timeout, consulta In che modo è possibile evitare gli errori di timeout del gateway HTTP 504 nel Servizio OpenSearch di Amazon?

Ottimizza la configurazione

Gestisci l'attività di rimozione di oggetti inutili (garbage collection)

Un'attività di rimozione di oggetti inutili (garbage collection) frequente o prolungata potrebbe causare problemi di prestazioni di ricerca, sospendere i thread o aumentare la latenza di ricerca. Per le best practice per ridurre i tempi di raccolta dei rifiuti, consulta A heap of trouble: Managing Elasticsearch's managed heap (Come gestire l'heap gestito di Elasticsearch) sul sito web Elastic.

Ottimizza lo spazio di archiviazione delle istanze

Il tipo di istanza Amazon Elastic Compute Cloud (Amazon EC2) può utilizzare uno spazio di archiviazione ottimizzato per Amazon Elastic Block Store (Amazon EBS) o volumi di archivio dell'istanza. I volumi di archivio dell'istanza possono aiutare a risolvere i colli di bottiglia di I/O perché offrono uno spazio di archiviazione direttamente collegato e funzionalità IOPS più elevate. Tuttavia, le istanze ottimizzate per Amazon EBS offrono uno spazio di archiviazione persistente con prestazioni costanti. Scegli un tipo di spazio di archiviazione in linea con i requisiti di configurazione del caso d'uso, tenendo conto di fattori quali I/O, persistenza dei dati e costi.

Prima di modificare il tipo di istanza, è consigliabile verificare le prestazioni dei diversi tipi di istanza per accertarsi che soddisfino i requisiti del carico di lavoro. Per un elenco dei tipi di istanze del Servizio OpenSearch disponibili, consulta i prezzi del Piano gratuito e delle Istanze on demand in Prezzi del Servizio OpenSearch di Amazon.

Nota: se il cluster si trova in un cloud privato virtuale (VPC), è consigliabile eseguire le applicazioni all'interno dello stesso VPC.

Semplifica la configurazione di shard e segmenti

Un cluster con troppi shard potrebbe aumentare l'utilizzo delle risorse, anche quando il cluster è inattivo. Troppi shard rallentano le prestazioni delle query. Sebbene un numero maggiore di shard di replica consenta ricerche più rapide, non utilizzare più di 1.000 shard in un singolo nodo. Inoltre, assicurati che le dimensioni degli shard siano comprese tra 10 GiB e 50 GiB. È consigliabile impostare il numero massimo di shard in un nodo in modo che corrisponda a 20 volte la dimensione dell'heap. Per informazioni sulla reindicizzazione e sulla modifica della strategia di sharding, consulta Optimize OpenSearch index shard sizes (Ottimizzazione delle dimensioni degli shard dell'indice OpenSearch) sul sito web OpenSearch.

Anche troppi segmenti o documenti eliminati possono influire sulle prestazioni di ricerca. Per migliorare le prestazioni, utilizza force merge sugli indici di sola lettura e aumenta l'intervallo di aggiornamento sugli indici attivi. Per ulteriori informazioni, consulta Force merge API (API force merge) e Optimize OpenSearch refresh interval (Ottimizzazione dell’intervallo di aggiornamento di OpenSearch) sul sito web OpenSearch.

Prima di aggiungere shard di replica a tutti i nodi, valuta i requisiti dell'applicazione. Se l'applicazione deve cercare tutti i dati da qualsiasi nodo, aumenta il numero di shard di replica per aumentare la disponibilità dei dati. In caso contrario, potresti non aver bisogno di shard di replica su ogni nodo.

Nota: gli shard di replica consentono ai cluster di utilizzare l'elaborazione parallela e distribuire le richieste di ricerca su più copie dei dati. Di conseguenza, le prestazioni di ricerca migliorano. Tuttavia, le operazioni di indicizzazione diventano più lente e serve spazio di archiviazione aggiuntivo per ogni copia completa dei dati.

Per gli indici con molti shard, utilizza il routing personalizzato per migliorare le prestazioni di ricerca. Con il routing personalizzato, esegui query solo sugli shard che contengono i dati voluti anziché su tutti gli shard. Per configurare il routing personalizzato, consulta Customizing your document routing (Personalizzazione del routing dei documenti) sul sito web Elastic.

Utilizza l'archiviazione Ultrawarm per dati di sola lettura

L'archiviazione a caldo offre le prestazioni più veloci per indicizzare e cercare nuovi dati. Tuttavia, i nodi UltraWarm sono un modo conveniente per archiviare grandi quantità di dati di sola lettura nel cluster. Per gli indici di sola lettura che non richiedono prestazioni elevate, utilizza UltraWarm anziché l'archiviazione dei dati a caldo.

Aumenta la velocità di ricerca

Cerca nel minor numero di campi possibile ed evita script e query con caratteri jolly. Per ulteriori informazioni, consulta Tune for search speed (Ottimizza la velocità di ricerca) sul sito web Elastic.