Come aumentare Redis prestazioni quando il 100% della CPU? Sharding? Il più veloce .Net Client?

A causa della massiccia aumenta il carico sul nostro sito redis è ora alle prese con un carico di picco, perché il redis dell’istanza del server di raggiungere il 100% della CPU (su uno degli otto core) con conseguente time out.

Abbiamo aggiornato il nostro software client per ServiceStack V3 (provenienti da BookSleeve 1.1.0.4) e aggiornato il redis server 2.8.11 (provenienti da 2.4.x). Ho scelto ServiceStack a causa dell’esistenza di Porto.RedisSessionStateStore che utilizza ServiceStack.Redis. Abbiamo usato AngiesList.Redis prima insieme con BookSleeve, ma abbiamo vissuto al 100% con che troppo.

Abbiamo otto redis server configurato come master/slave albero. Un singolo server per lo stato della sessione tho. Gli altri sono per la cache di dati. Un master con due master/slave collegati a due schiavi ogni.

Il server di contenere circa 600 connessioni client di picco fino a quando inizia ad intasarsi il 100% di CPU.

Cosa possiamo fare per aumentare le prestazioni?

Sharding e/o StackExchange Redis client (non lo stato di sessione client a disposizione la mia conoscenza…).

O potrebbe essere qualcos’altro? La sessione del server colpisce anche il 100% e non è collegato a qualsiasi altro server (dati e la velocità di rete sono bassi).


Aggiornamento 1: Analisi di redis-cli INFO

Ecco l’output del comando INFO dopo una notte di esecuzione di Redis 2.8.

# Server
redis_version:2.8.11
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:7a57b118eb75b37f
redis_mode:standalone
os:Linux 2.6.32-431.11.2.el6.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.7
process_id:5843
run_id:d5bb838857d61a9673e36e5bf608fad5a588ac5c
tcp_port:6379
uptime_in_seconds:152778
uptime_in_days:1
hz:10
lru_clock:10765770
config_file:/etc/redis/6379.conf

# Clients
connected_clients:299
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

# Memory
used_memory:80266784
used_memory_human:76.55M
used_memory_rss:80719872
used_memory_peak:1079667208
used_memory_peak_human:1.01G
used_memory_lua:33792
mem_fragmentation_ratio:1.01
mem_allocator:jemalloc-3.2.0

# Persistence
loading:0
rdb_changes_since_last_save:70245
rdb_bgsave_in_progress:0
rdb_last_save_time:1403274022
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

# Stats
total_connections_received:3375
total_commands_processed:30975281
instantaneous_ops_per_sec:163
rejected_connections:0
sync_full:10
sync_partial_ok:0
sync_partial_err:5
expired_keys:8059370
evicted_keys:0
keyspace_hits:97513
keyspace_misses:46044
pubsub_channels:2
pubsub_patterns:0
latest_fork_usec:22040

# Replication
role:master
connected_slaves:2
slave0:ip=xxx.xxx.xxx.xxx,port=6379,state=online,offset=272643782764,lag=1
slave1:ip=xxx.xxx.xxx.xxx,port=6379,state=online,offset=272643784216,lag=1
master_repl_offset:272643811961
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:272642763386
repl_backlog_histlen:1048576

# CPU
used_cpu_sys:20774.19
used_cpu_user:2458.50
used_cpu_sys_children:304.17
used_cpu_user_children:1446.23

# Keyspace
db0:keys=77863,expires=77863,avg_ttl=3181732
db6:keys=11855,expires=11855,avg_ttl=3126767

Aggiorna 2: twemproxy (Sharding)

Ho scoperto un interessante componente chiamato twemproxy. Questo componente, da quanto ho capito, potrebbe Shard in più redis istanze.

Sarebbe questo contribuire ad alleviare la CPU?

Ci farebbe risparmiare un sacco di tempo di programmazione, ma sarebbe comunque richiedere un certo sforzo per configurare 3 istanze in ogni server. Così sto sperando che qualcuno può confermare o sfatare questa soluzione prima di mettere in opera.

Puoi chiarire: è Redis che ha elevato della cpu, o il vostro livello di web? Questo è importante essere chiari. Qual è il funzionamento? (Redis mostra istantanea opcount via “info”)
Ho chiarito il post. Dovrò guardare il opcount. Il comando info è molto lento durante questi carichi.

OriginaleL’autore baskabas | 2014-06-19

3 Replies
  1. 3

    Il mio primo, semplice suggerimento, se non l’hai già fatto, sarebbe quello di spegnere tutte le RDB o AOF backup sul vostro Master almeno. Naturalmente poi i vostri schiavi potrebbe cadere dietro di se hanno ancora il salvataggio su disco. Vedere questo per un’idea del costo di RDB discariche

    Un’altra cosa da fare è assicurarsi che si sta pipelining di tutti i comandi. Se stai inviando molti singolarmente i comandi che possono essere raggruppati in una conduttura si dovrebbe vedere un urto in termini di prestazioni.

    Anche, questo post ha una buona risposta su profilatura Redis

    Maggiori informazioni circa il vostro caso d’uso, e la struttura dei dati utili a decidere se c’è una semplice modifica si potrebbe fare per il modo in cui si sta effettivamente utilizzando Redis, che vi darà un miglioramento.

    Modifica: In risposta al tuo ultimo commento, è bene notare che ogni volta che si dispone di uno schiavo perde la connessione e si riconnette, si ri-sincronizzazione con il maestro. Nelle versioni precedenti di Redis questo è sempre stato un completo re-sync, quindi era piuttosto costoso. A quanto pare a 2.8 lo schiavo è ora in grado di richiedere una parziale ri-sincronizzazione di solo i dati che perdere dal momento che è la disconnessione. Non so molto sui dettagli, ma se il master o uno qualsiasi dei vostri schiavi non sono 2.8.* e si dispone di una connessione traballante, che potrebbe davvero danneggiare le vostre prestazioni della cpu da sempre forzare il tuo master a ri-sincronizzare gli schiavi. Ulteriori informazioni Qui

    Io sono disposto a provare questo. Qualcuno potrebbe confermare che questo non introdurre altri problemi.
    Ho trovato anche un’impostazione denominata rdbcompression = true. Potrebbe salvare la disattivazione di questa CPU? O il file più grande sarà la prossima ” collo di bottiglia? Abbiamo più che sufficiente memoria.
    che non presenta altri problemi? la disattivazione di RDB backup? Abbiamo eseguito i nostri master e uno slave come memoria di sola. Non RDB o AOF. Abbiamo poi un altro disco slave che gestisce la creazione del nostro disco di backup. Non provoca “altri problemi”… stai solo dando la redis-processo server meno lavoro da fare.
    sì, la disattivazione rdbcompression dovrebbe ridurre l’utilizzo della CPU. Ma solo se siete realmente risparmio rdb backup sul master, che sto suggerendo di non fare. Backup del disco sono un grande lavoro per una macchina slave…
    Sì, grazie wallacer. Ho letto l’argomento. Abbiamo disabilitato il salvataggio di RDB dal momento che non ne abbiamo bisogno. AOF è stata disattivata per impostazione predefinita.

    OriginaleL’autore wallacer

  2. 3

    Abbiamo trovato un problema all’interno della nostra applicazione. Comunicazione sull’aggiornamento dei dati nella cache locale di memoria cache è stata realizzata attraverso un redis sottoscrizione di canale.

    Ogni volta cache locale si era svuotato, gli articoli scaduti o gli elementi sono stati aggiornati messaggi che ha mandato a tutti (35) webservers che a sua volta avviato l’aggiornamento più oggetti, ecc, ecc.

    Disabilitare i messaggi per le chiavi aggiornate migliorato la nostra situazione di 10 volte.

    Larghezza di banda della rete è sceso a 1,2 Gbps a 200Mbps e l’utilizzo della CPU è del 40% al 150% del carico che abbiamo avuto finora in un momento di estrema calcoli e gli aggiornamenti.

    Interessante risposta e un problema interessante. Per chiarire, si è utilizzato Redis pub/sub per mantenere memorizza nella cache i 35 web caselle in sincronia, è corretto? C’era qualche motivo particolare che hai utilizzato, per esempio utilizzando i tasti di comando, come è stato suggerito in una delle risposte? Anche al di fuori di interessi, che tipo di CPU spec è stato il Redis macchina?
    Niente di particolare, basta inviare un messaggio quando un tasto viene aggiornato nel nostro CacheManager e rimuovere la chiave dal locale memcache su l’altra estremità. CPU: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz.

    OriginaleL’autore baskabas

  3. 2

    La prima cosa da fare sarebbe quella di guardare a slowlog get 50 (o di scegliere un qualsiasi numero di righe) – questo mostra l’ultimo 50 comandi che ha preso non banale quantità di tempo. Potrebbe essere che alcune delle cose che si stanno facendo sono semplicemente prendendo troppo tempo. Mi preoccupo se vedo nulla in slowlog – io di solito vedere gli oggetti ogni pochi giorni. Se si sta vedendo un sacco di elementi costantemente, quindi: è necessario indagare su ciò che si sta effettivamente facendo sul server. Un killer di cosa da non fare mai è keys, ma ci sono altre cose.

    La prossima cosa da fare è: cache. Le richieste che fare corto prima che colpiscano il back-end sono libero. Usiamo redis ampiamente, ma questo non significa che non possiamo ignorare memoria locale.

    Slowlog mostra 71 voci (e contare) sul nostro cache di sessione e 128 voci e contando sulla cache di dati. Non siamo al sacco di carico al momento. Quanto tempo voci di rimanere qui? Sono questi conta molto?
    che non suona come esso è continuo, almeno – a meno che non sia semplicemente tagliato a quel numero. Ci sono delle volte in maniera offensiva grande? Mi preoccupo a qualcosa di più di 5ms. Ma la prossima cosa da guardare sarebbe “monitor” (brevemente), per vedere quello che il server è in realtà facendo.
    Puoi spiegarti meglio il tuo ultimo commento (nella risposta)? Usiamo locale memcache sul nostro server web per alleggerire il carico dei nostri cache. Perché corriamo 2 lavoratori, ci sono ora anche mettendo un’istanza locale di redis su ogni webserver. Che cosa accadrebbe se noi li renderebbe schiavi?
    la maggior parte delle voci sono tra 10ms-20ms. Due stand, sia “PSYNC ? -1” 80 ms-105ms. Di nuovo abbiamo solo 750 utenti simultanei adesso… la scorsa notte abbiamo raggiunto 10K+. Ho monitorato un bel paio di volte e vedo un sacco di tasti (e i loro dati), passando dal. Cosa vorresti essere?
    psync è la replica, ma che non suono terribile. Monitor sarebbe il mio prossimo passo.

    OriginaleL’autore Marc Gravell

Lascia un commento