2013-03-07 10 views
5

Provare una latenza di risposta molto elevata con Redis, al punto di non riuscire a fornire informazioni quando si utilizza il comando info tramite redis-cli.Redis impiega troppo tempo a rispondere

Questo server gestisce le richieste da circa 200 processi simultanei ma non memorizza troppe informazioni (almeno a nostra conoscenza). Quando il server è reattivo, il comando info segnala una memoria di circa 20 - 30 MB.

Quando si esegue top sul server, durante periodi di elevata latenza di risposta, l'utilizzo della CPU è intorno al 95 - 100%.

Quali sono alcune possibili cause per questo tipo di comportamento?

+0

Che aspetto ha il tuo utilizzo? C'è un sacco di grandi 'SORT' sta succedendo? Utilizzi 'KEYS' nel codice di produzione? Stai eseguendo il 'MONITOR' da qualche parte? Qual è la tua strategia di persistenza? –

+0

Abbiamo disabilitato la persistenza in questa istanza. Attualmente non si usano i comandi 'KEYS' o' MONITOR' ovunque. Non abbiamo nemmeno "SORT", almeno per quanto ne so. Questa istanza è dedicata a 'rq' (www.python-rq.org). –

risposta

8

È difficile proporre una spiegazione solo in base ai dati forniti, ma ecco la mia ipotesi. Suppongo che tu abbia già controllato le ovvie sorgenti di latenza (quelle legate alla persistenza), che nessun comando di Redis stia tracciando la CPU nel slow log e che la dimensione dei dati del lavoro decapitati da Python-rq non sia enorme.

In base alla documentazione, Python-rq inserisce i lavori in Redis come oggetti hash e lascia che Redis scada i tasti relativi (500 secondi sembra essere il valore predefinito) per eliminare i lavori. Se si dispone di un certo throughput serio, in un punto, si avranno molti elementi in Redis in attesa di essere scaduti. Il loro numero sarà elevato rispetto ai lavori in sospeso.

È possibile controllare questo punto osservando il numero di elementi che devono essere scaduti nel risultato del comando INFO.

La scadenza di Redis si basa su un meccanismo pigro (applicato quando si accede a una chiave) e su un meccanismo attivo basato sul campionamento della chiave, che viene eseguito nel ciclo di eventi (in modalità pseudo sfondo, ogni 100 ms). Il punto è quando il meccanismo di scadenza attivo è in esecuzione, nessun comando Redis può essere elaborato.

Per evitare un impatto eccessivo sulle prestazioni delle applicazioni client, viene elaborato solo un numero limitato di chiavi ogni volta che viene attivato il meccanismo attivo (per impostazione predefinita, 10 chiavi). Tuttavia, se si scopre che oltre il 25% delle chiavi è scaduto, tenta di scadere più chiavi e cicli. Questo è il modo in cui questo algoritmo probabilistico adatta automaticamente la sua attività al numero di chiavi che Redis deve scadere.

Quando molte chiavi devono essere scadute, questo algoritmo adattivo può influire significativamente sulle prestazioni di Redis. Puoi trovare ulteriori informazioni here.

Il mio suggerimento sarebbe di cercare di impedire a Python-rq di delegare la pulizia degli elementi a Redis impostando la scadenza. Questo è comunque un design scarso per un sistema di accodamento.

+0

Sembra un'ottima soluzione. Grazie per una risposta così elaborata. Lo proverò e vedrò come funziona. Grazie ancora! –

+0

Sì, notando un ridotto utilizzo della CPU quando si riduce 'Job' ttl. Grazie mille! –

0

Penso che ridurre ttl non dovrebbe essere il modo giusto per evitare l'utilizzo della CPU quando le chiavi di scadenza scadono.

Didier afferma, con un buon punto, che l'architettura corrente di Python-rq che delega i processi di pulizia a Redis utilizzando la funzione di scadenza della chiave. E sicuramente, come Didier ha detto che non è il modo migliore. (questo è usato solo quando result_ttl è maggiore di 0)

Quindi il problema dovrebbe sorgere quando si ha un set di chiavi/lavori con una data di scadenza vicino a una dell'altra, e potrebbe essere fatto quando si hanno delle raffiche di creazione di posti di lavoro.

set

Ma Python-RQ chiave scadono quando il lavoro è stato completato in un lavoratore,

Poi non ha troppo senso, perché le chiavi dovrebbero diffuso in tutto il tempo con il tempo sufficiente tra loro per evitare questo situazione