Alcuni sistemi Linux diventano molto lenti quando Redis sta caricando un grande set di dati

Ho ricevuto un rapporto da un utente Redis, e non sono sicuro di cosa rispondere in quanto non sono un esperto nell'area di Linux e del suo programmatore, tuttavia noi (come il progetto Redis) abbiamo bisogno di capire questo tipo di problemi soprattutto in futuro, come con Redis Cluster, avremo molte istanze di Redis in esecuzione contemporaneamente in una singola casella. Quindi sto chiedendo aiuto qui.

Problema:

• Kernel: "Linux redis1 2.6.32-305-ec2 # 9-Ubuntu SMP Gio 15 Apr 08:05:38 UTC 2010 x86_64 GNU / Linux"
• molta RAM libera, nessun altro processo esegue I / O significativi.
• Importante , in esecuzione su una grande istanza EC2, non un vero server. Non ho mai visto qualcosa del genere in un ambiente non virtualizzato. L'istanza EC2 era: "Memoria ad alta memoria da 17,1 GB di memoria ad alta memoria, 6,5 ECU (2 core virtuali con 3,25 unità di calcolo EC2 ciascuno), 420 GB di memoria di istanza locale, piattaforma a 64 bit" .

Fondamentalmente, una volta riavviata una grande istanza Redis, il sistema diventerà così lento che non sarà più possibile digitare sulla shell. Quando Redis carica un'istanza, utilizza il 100% della CPU (carica i dati il ​​più velocemente possibile) e legge il file dump.rdb in sequenza. L'I / O non è particolarmente elevato poiché il caricamento è associato alla CPU, non agli I / O.

Perché mai una scatola con due CPU e molta RAM, nessuna cosa scambiata su disco, dovrebbe praticamente smettere di funzionare con questo carico di lavoro?

Ho l'impressione che questo abbia molto a che fare con il fatto che si tratta di un'istanza EC2, quindi correlata alla tecnologia di virtualizzazione utilizzata, poiché carico tutte le volte i set di dati Redis da 24 GB nella mia scatola senza alcun problema (anche con altre istanze di Redis in esecuzione con carico elevato).

Grazie per qualsiasi suggerimento!

Salvatore

Modifica : aggiungendo alcuni feedback che ho ricevuto da Twitter:

da @ezmobius: @antirez la prima cosa da fare è provarlo da / mnt o dalle unità effimere locali per vedere se il suo difetto di EBS, 2 ° è assicurarsi che non sia la "penalità di prima scrittura" (google it) e se è quindi devi prima inserire 0 su tutto il disco.

da @dvirsky: @antirez Sto eseguendo molte istanze redis esattamente su tali nodi ec2. Ho notato qualche rallentamento su bgsave ma non questo fenomeno.

L'output di "top" potrebbe fornire alcuni indizi. C'è un campo in alto a sinistra etichettato '% rubato' che riflette la quantità di CPU hardware trasferita ad altri guest sulla stessa scatola fisica. Ho visto questo tipo di rallentamenti quando l'hypervisor decide di allocare più CPU a un altro ospite, in particolare quando eseguo attività ad uso intensivo di CPU a lungo termine.

Non sono sicuro se questo è il tuo problema o no, ma vale la pena verificarlo.

Ho avuto lo stesso problema su un'istanza EC2. Probabilmente non è correlato a Redis: si verifica quando è in corso un IO elevato (ad es. Quando redis sta caricando un file di dump).

Dai un'occhiata a questa discussione sui forum di Amazon: https://forums.aws.amazon.com/thread.jspa?messageID=215406

Ho sperimentato diversi kernel / immagini e ora funziona bene (su un vecchio kernel 2.6.21).

Dovresti controllare il furto della CPU ( xx.x%stsul lato destro della linea della CPU) che topmostra quando si verifica il carico del 100% e la shell congelata. Ruba rappresenta la quantità di cicli CPU effettiva rubata dal computer da un hypervisor e assegnata a un altro computer. Il furto della CPU è rilevante solo negli ambienti virtualizzati. Ho avuto quel problema esatto con le microistanze e che sostanzialmente ha reso la mia istanza inutilizzabile per circa 1 ora o giù di lì (fino a quando il mio compito non è terminato) se eseguo attività ad alta intensità di CPU.

Puoi trovare ulteriori informazioni su questo argomento leggendo questo post su Greg's Ramblings . Tuttavia, se prendi la parola di Greg, questo dovrebbe accadere solo su microistanze.