Sto eseguendo il benchmarking di ElasticSearch per scopi di throughput di indicizzazione molto elevati.ElasticSearch - throughput di indicizzazione elevata
Il mio obiettivo attuale è riuscire a indicizzare 3 miliardi (3.000.000.000) di documenti in poche ore. A tale scopo, attualmente dispongo di 3 macchine server Windows, con 16 GB di RAM e 8 processori ciascuno. I documenti inseriti hanno una mappatura molto semplice, contenente solo una manciata di campi numerici non analizzati (_all disabilitato).
Sono in grado di raggiungere circa 120.000 richieste di indice al secondo (monitoraggio utilizzando una grande scrivania), utilizzando questo rig relativamente modesto, e sono fiducioso che il rendimento possa essere ulteriormente aumentato. Sto usando un numero di client NEST .net per inviare le richieste di massa dell'indice, con 1500 operazioni di indice in blocco.
Sfortunatamente, il throughput di 120k richieste al secondo non dura molto a lungo, e il tasso diminuisce gradualmente, scendendo a ~ 15k dopo un paio d'ore.
Il monitoraggio delle macchine rivela che le CPU non sono il collo di bottiglia. Tuttavia, il tempo di inattività del disco fisico (non SSD) sembra essere in calo su tutte le macchine, raggiungendo meno del 15% del tempo di inattività.
L'impostazione da refresh_interval a 60 s, che a 300 s, e infine a 15 m, non sembra essere di grande aiuto. Spiando su una singola finestra di dialogo in un singolo frammento, ha mostrato che il translog viene svuotato ogni 30 minuti, prima di raggiungere 200 MB.
Ho provato con due strategie: sharding
- 1 indice, con 60 frammenti (senza repliche).
- 3 indici, con 20 frammenti ciascuno (nessuna replica).
Entrambi i tentativi si traducono in un'esperienza piuttosto simile, che a mio avviso ha senso poiché è lo stesso numero di frammenti.
Guardando i segmenti, vedo che la maggior parte dei frammenti ha ~ 30 segmenti impegnati e un numero simile di segmenti ricercabili. La dimensione del segmento varia. Un tempo, un tentativo di ottimizzare l'indice con max_num_segments = 1, sembrava avere un po 'di aiuto dopo che era finito (ha impiegato molto tempo).
In qualsiasi momento, l'avvio dell'intero processo di importazione dall'inizio, dopo l'eliminazione degli indici utilizzati e la creazione di nuovi, comporta lo stesso comportamento. Inizialmente alto indice di rendimento, ma gradualmente diminuendo, molto prima di raggiungere l'obiettivo di 3 miliardi di documenti. La dimensione dell'indice in quel momento è di circa 120 GB.
Sto usando la versione 1.4 di ElasticSearch. Xms e Xmx sono configurati per 8192 MB, il 50% della memoria disponibile. Il buffer di indicizzazione è impostato su 30%.
Le mie domande sono le seguenti:
- Supponendo che il disco è attualmente il collo di bottiglia di questo impianto di perforazione, è questo fenomeno di via via crescente utilizzo del disco è uno normale? In caso contrario, cosa si può fare per annullare questi effetti?
- È possibile eseguire regolazioni di precisione per aumentare il throughput dell'indicizzazione? Dovrei? o dovrei semplicemente scalare.
Qual è l'ingombro della memoria di processo nel tempo? il throughput si stabilizza a 15k/s o continua a scendere? cosa sta per/da disco? (su Linux, alcuni di questi disponibili con ps o top, alcuni con strace) – Andras
Non ricordo l'esatta impronta di memoria, aggiornerò domani. Tuttavia, ricordo un grafico piuttosto sano di un puzzle. Il tasso di indicizzazione sembra stabilizzarsi a 15k/s, tuttavia occorrerebbero ore per verificarlo. Su ogni macchina, il servizio elasticsearch esegue circa 2MG/s in scrittura (inizialmente - è molto meno quando la frequenza si attenua), e quando il disco è occupato, 50 - 80 MG/s legge. – Roman
Stai specificando le chiavi per i documenti o stai permettendo a Elasticsearch di generare automaticamente gli ID? Hai provato a usare meno frammenti? –