Come posso risolvere i picchi di latenza di ricerca nel cluster del servizio OpenSearch di Amazon?

8 minuti di lettura
0

Ho dei picchi di latenza di ricerca nel cluster del servizio OpenSearch di Amazon.

Breve descrizione

Per le richieste di ricerca, OpenSearch Service calcola il tempo di andata e ritorno come segue:

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

La metrica SearchLatency su Amazon CloudWatch indica il tempo impiegato dalla query nella fase di interrogazione.

Per risolvere i picchi di latenza della ricerca nel cluster di OpenSearch Service, è possibile eseguire diversi passaggi:

  • Verifica la presenza di risorse insufficienti fornite nel cluster
  • Verifica la presenza di ricerche rifiutate utilizzando la metrica ThreadpoolSearchRejected in CloudWatch
  • Usa l'API search slow logs e l'API profile
  • Risolvi eventuali errori di timeout del gateway 504

Risoluzione

Verifica la presenza di risorse insufficienti fornite nel cluster

Se il tuo cluster dispone di risorse insufficienti, è possibile che si verifichino picchi di latenza nella ricerca. Utilizza le seguenti best practice per assicurarti di disporre di risorse sufficienti.

  1. Esamina la metrica di CPUUtilization e la pressione JVMMemory del cluster utilizzando CloudWatch. Verifica che rientrino nelle soglie consigliate. Per ulteriori informazioni, consulta Allarmi CloudWatch consigliati per Amazon OpenSearch Service.

  2. Usa l'API delle statistiche dei nodi per ottenere statistiche a livello di nodo sul tuo cluster:

GET /_nodes/stats

Nell'output, controlla le seguenti sezioni: cache, fielddata e jvm. Per confrontare gli output, esegui questa API più volte con un certo ritardo tra ogni uscita.

  1. OpenSearch Service utilizza più cache per migliorare le prestazioni e il tempo di risposta delle richieste:
  • La cache del file system, o cache delle pagine, esistente a livello di sistema operativo
  • La cache delle richieste a livello di partizione e la cache delle query che esistono entrambe a livello di servizio OpenSearch

Esamina l'output dell'API Node stats per l'espulsione dalla cache. Un numero elevato di espulsioni della cache nell'output indica che la dimensione della cache è inadeguata per soddisfare la richiesta. Per ridurre le espulsioni, usa nodi più grandi con più memoria.

Per visualizzare informazioni specifiche sulla cache con l'API delle statistiche dei nodi, utilizza le seguenti richieste. La seconda richiesta riguarda una cache di richieste a livello di condivisione:

GET /_nodes/stats/indices/request_cache?human

GET /_nodes/stats/indices/query_cache?human

Per ulteriori informazioni sulle cache di OpenSearch, consulta Elasticsearch caching deep dive: Aumenta la velocità delle query una cache alla volta sul sito Web Elastic.

Per i passaggi per cancellare le varie cache, consulta Cancellare la cache dell'indice o del flusso di dati nel sito Web di OpenSearch.

  1. L'esecuzione di aggregazioni su campi che contengono valori altamente univoci potrebbe causare un aumento dell'utilizzo dell'heap. Se le query di aggregazione sono già in uso, le operazioni di ricerca utilizzano fielddata. Fielddata ordina e accede anche ai valori dei campi nello script. Le espulsioni di fielddata dipendono dalla dimensione del file indices.fielddata.cache.size e questo rappresenta il 20% dello spazio dell'heap JVM. Quando la cache viene superata, l'espulsione inizia.

Per visualizzare la cache di fielddata, utilizza questa richiesta:

GET /_nodes/stats/indices/fielddata?human

Per ulteriori informazioni sulla risoluzione dei problemi relativi alla memoria JVM elevata, consulta Come posso risolvere l'elevata pressione della memoria JVM sul mio cluster Amazon OpenSearch Service?
Per risolvere i problemi di utilizzo elevato della CPU, vedi Come posso risolvere i problemi di utilizzo elevato della CPU sul mio cluster Amazon OpenSearch Service?

Verifica la presenza di ricerche rifiutate utilizzando la metrica ThreadpoolSearchRejected in CloudWatch

Per verificare la presenza di ricerche rifiutate utilizzando CloudWatch, segui i passaggi in Come posso risolvere i rifiuti di ricerca o scrivere in Amazon OpenSearch Service?

Usa gli slow log di ricerca per identificare le query di lunga durata

Per identificare sia le query di lunga durata che il tempo impiegato da una query su una particolare partizione, utilizza gli slow log. È possibile impostare soglie per la fase di interrogazione e quindi recuperare la fase per ogni indice. Per ulteriori informazioni sulla configurazione degli slow log, consulta Visualizzazione degli slow log di Amazon Elasticsearch Service. Per un'analisi dettagliata del tempo impiegato dalla tua query nella fase di ricerca, imposta "profile":true per la tua query di ricerca.

Nota: se si imposta la soglia per la registrazione su un valore molto basso, la pressione della memoria JVM potrebbe aumentare. Ciò potrebbe portare a una rimozioni di oggetti inutili (garbage collection) più frequente che aumenta l'utilizzo della CPU e aumenta la latenza del cluster. La registrazione di più richieste potrebbe anche aumentare i costi. Un lungo output dell'API del profilo aggiunge anche un notevole sovraccarico a qualsiasi query di ricerca.

Risolvi eventuali errori di timeout del gateway 504

Dai log delle applicazioni del tuo cluster OpenSearch Service, puoi visualizzare codici di errore HTTP specifici per le singole richieste. Per ulteriori informazioni sulla risoluzione degli errori di timeout del gateway HTTP 504, consulta Come posso prevenire gli errori di timeout del gateway HTTP 504 in Amazon OpenSearch Service?

Nota: è necessario attivare i log degli errori per identificare codici di errore HTTP specifici. Per ulteriori informazioni sui codici di errore HTTP, consulta Visualizzazione dei log degli errori di Amazon OpenSearch Service.

Altri fattori che possono causare un'elevata latenza di ricerca

Esistono numerosi altri fattori che possono causare un'elevata latenza di ricerca. Utilizza i seguenti suggerimenti per risolvere ulteriormente i problemi di latenza di ricerca elevata:

  • Un'attività di rimozione di oggetti inutili (garbage collection) frequente o prolungata potrebbe causare problemi di prestazioni di ricerca. L'attività di rimozione di oggetti inutili (garbage collection) potrebbe sospendere i thread e aumentare la latenza della ricerca. Per ulteriori informazioni, consulta A heap of trouble: Gestione dell'heap gestito di Amazon OpenSearch Service sul sito Web Elastic.
  • La capacità di IOPS allocata (o istanze i3) può aiutarti a rimuovere qualsiasi collo di bottiglia di Amazon Elastic Block Store (Amazon EBS). Nella maggior parte dei casi, non ne hai bisogno. Prima di spostare un'istanza su i3, è consigliabile testare le prestazioni tra nodi i3 e nodi r5.
  • Un cluster con troppe partizioni può aumentare l'utilizzo delle risorse, anche quando il cluster è inattivo. Troppe partizioni rallentano le prestazioni delle query. Sebbene aumentare il numero di frammenti di replica possa aiutarti a eseguire ricerche più rapide, non superare i 1000 frammenti su un determinato nodo. Inoltre, assicurati che le dimensioni dei frammenti siano comprese tra 10 GiB e 50 GiB. Idealmente, il numero massimo di frammenti su un nodo è heap * 20.
  • Troppi segmenti o troppi documenti eliminati potrebbero influire sulle prestazioni di ricerca. Per migliorare le prestazioni, usa force merge sugli indici di sola lettura. Inoltre, aumenta l'aggiornamento interno degli indici attivi, se possibile. Per ulteriori informazioni, consulta la gestione dei documenti eliminati da parte di Lucene sul sito Web di Elastic.
  • Se il tuo cluster si trova in un cloud privato virtuale (VPC), è consigliabile eseguire le applicazioni all'interno dello stesso VPC.
  • Usa i nodi UltraWarm o i nodi hot data per dati di sola lettura. L'hot storage offre le prestazioni più veloci possibili per l'indicizzazione e la ricerca di nuovi dati. Tuttavia, i nodi UltraWarm sono un modo conveniente per archiviare grandi quantità di dati di sola lettura sul cluster. Per gli indici su cui non è necessario scrivere e che non richiedono prestazioni elevate, UltraWarm offre costi per GiB di dati notevolmente inferiori.
  • Stabilisci se il tuo carico di lavoro trae vantaggio dalla disponibilità dei dati che stai cercando su tutti i nodi. Alcune applicazioni traggono vantaggio da questo approccio, soprattutto se nel cluster sono presenti pochi indici. A tale scopo, aumenta il numero di frammenti di replica.
    Nota: ciò potrebbe aumentare la latenza di indicizzazione. Inoltre, potresti aver bisogno di spazio di archiviazione Amazon EBS aggiuntivo per ospitare le repliche che aggiungi. Ciò aumenta i costi di volume di EBS.
  • Cerca nel minor numero di campi possibile ed evita script e query con caratteri jolly. Per ulteriori informazioni, consulta Tune for search speed sul sito Web di Elastic.
  • Per gli indici con molte partizioni, utilizza un routing personalizzato per velocizzare le ricerche. Il routing personalizzato consente di interrogare solo le partizioni che contengono i dati, anziché trasmettere la richiesta a tutte le partizioni. Per ulteriori informazioni, consulta Personalizzazione del routing dei documenti sul sito Web di Elastic.

Informazioni correlate

Allarmi CloudWatch consigliati per Amazon OpenSearch Service

AWS UFFICIALE
AWS UFFICIALEAggiornata un anno fa