Einführung in Redis-Leistungsanalyse- und Überwachungslösungen

1. Redis-Slowlog-Analyse

SLOWLOG-Unterbefehl [Argument]

Im Folgenden sind die langsamen Abfragekonfigurationsparameter von Redis aufgeführt .conf :

slowlog-log-slower-than 10000     #查询时间超过10ms的会被记录
slowlog-max-len 128     #最多记录128个慢查询

Die oben genannten Parameter können dynamisch abgefragt oder in Redis festgelegt werden: Verwenden Sie die Befehle config get und config set

um langsame Abfragen zu lesen: Sie können die angegebenen wenigen langsamen Abfragen erhalten

127.0.0.1:6320> slowlog get 1
 1) 1) (integer) 394689     #slowlog的唯一编号
    2) (integer) 1480851711     #此次slowlog事件的发生时间
    3) (integer) 10639     #耗时
    4) 1) "HGET"     #slowlog事件所对应的redis 命令
       2) "hash:submit_sent_150004"
       3) "15000429648122734363745165312"

Slowlog-Statistiken zurücksetzen:

SLOWLOG RESET

Redis-Langsambefehlsanalyse:

1. Das Ergebnis ist Wenn die Anfrage langsam bedient wird, warten alle anderen Clients auf die Bearbeitung dieser Anfrage. Wenn Sie viele langsame Befehle ausführen müssen, wird empfohlen, langsame Abfragen zur Ausführung an den Redis-Slave zu senden.

2. Über den Befehl „keys“: Eine sehr häufige Ursache für Verzögerungen, die durch die Ausführung langsamer Befehle verursacht werden, ist die Verwendung des Befehls „KEYS“ in einer Produktionsumgebung. Wie in der Redis-Dokumentation angegeben, sollten KEYS nur für Debugging-Zwecke verwendet werden.

Redis2.8 hat neue Befehle zum Abfragen großer Sammlungen eingeführt. Weitere Informationen finden Sie in den Befehlen SCAN, SSCAN, HSCAN und ZSCAN.

• SCAN iteriert über den Schlüsselsatz in der aktuell ausgewählten Redis-Datenbank.

• SSCAN iteriert über Elemente des Sammlungstyps „Sets“.

• HSCAN iteriert über Felder von Hash-Typen und den zugehörigen Werten.

• ZSCAN iteriert über Elemente des Typs „Sortierte Menge“ und die zugehörigen Bewertungen.

Da diese Befehle eine inkrementelle Iteration ermöglichen und nur eine kleine Anzahl von Elementen pro Aufruf zurückgeben, können sie in der Produktion ohne die Nachteile von Befehlen wie KEYS oder SMEMBERS verwendet werden, die bei Aufruf A groß sind Das Sammeln von Schlüsseln oder Elementen kann den Server für lange Zeit (sogar Sekunden) blockieren.

2. So verwenden Sie die Befehle SCAN, SSCAN, HSCAN und ZSCAN

SCAN ist ein Cursor-basierter Iterator. Das bedeutet, dass der Server bei jedem Aufruf des Befehls einen aktualisierten Cursor zurückgibt, den der Benutzer beim nächsten Aufruf als Cursorparameter verwenden muss.

Die Iteration beginnt, wenn der Cursor auf 0 gesetzt ist, und endet, wenn der vom Server zurückgegebene Cursor 0 ist. Das Folgende ist ein Beispiel für eine SCAN-Iteration:

127.0.0.1:6319> scan 0
1) "65536"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
127.0.0.1:6319> scan 65536
1) "884736"
2)  1) "list:submit_sent_2016-12-01-17:55_175010"
    2) "list:submit_sent_2016-12-02-18:28_138052"
    3) "list:submit_sent_2016-12-01-18:17_150243"
    4) "list:submit_sent_2016-12-01-11:22_137606"
    5) "list:submit_sent_2016-12-01-21:15_183748"
    6) "list:submit_sent_2016-12-02-11:47_155212"
    7) "list:submit_sent_2016-12-01-11:01_137065"
    8) "list:submit_sent_2016-12-02-08:03_181202"
    9) "list:submit_sent_2016-12-02-12:16_136096"
   10) "list:submit_sent_2016-12-01-18:12_159893"

startet eine Iteration mit einem Cursorwert von 0 und ruft SCAN auf, bis der zurückgegebene Cursor wieder 0 ist, was als vollständige Iteration bezeichnet wird.

Die Zähloption des Scans: Geben Sie die Anzahl der Ausgaben an

127.0.0.1:6319> scan 0 count 20
1) "884736"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
   11) "list:submit_sent_2016-12-01-17:55_175010"
   12) "list:submit_sent_2016-12-02-18:28_138052"
   13) "list:submit_sent_2016-12-01-18:17_150243"
   14) "list:submit_sent_2016-12-01-11:22_137606"
   15) "list:submit_sent_2016-12-01-21:15_183748"
   16) "list:submit_sent_2016-12-02-11:47_155212"
   17) "list:submit_sent_2016-12-01-11:01_137065"
   18) "list:submit_sent_2016-12-02-08:03_181202"
   19) "list:submit_sent_2016-12-02-12:16_136096"
   20) "list:submit_sent_2016-12-01-18:12_159893"

Die Match-Option des Scans: Ähnlich wie bei der Tastenbefehlsübereinstimmung nach Muster, hängen Sie einfach den Parameter MATCH an Ende des SCAN-Befehls

127.0.0.1:6319> scan 0 match *submit_sent*
1) "65536"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
127.0.0.1:6319> scan 0 count 15  match *submit_sent*     #查找匹配的数据并返回15个
1) "2031616"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
   11) "list:submit_sent_2016-12-01-17:55_175010"
   12) "list:submit_sent_2016-12-02-18:28_138052"
   13) "list:submit_sent_2016-12-01-18:17_150243"
   14) "list:submit_sent_2016-12-01-11:22_137606"
   15) "list:submit_sent_2016-12-01-21:15_183748"

Die Methode zum Abfragen der Sets-Sammlung durch sscan:

redis 127.0.0.1:6379> sadd myset 1 2 3 foo foobar feelsgood
(integer) 6
redis 127.0.0.1:6379> sscan myset 0 match f*
1) "0"
2) 1) "foo"
   2) "feelsgood"
   3) "foobar"
redis 127.0.0.1:6379>

Die Methode zum Abfragen der Hash-Sammlung durch hscan:

redis 127.0.0.1:6379> hmset hash name Jack age 33
OK
redis 127.0.0.1:6379> hscan hash 0
1) "0"
2) 1) "name"
   2) "Jack"
   3) "age"
   4) "33"

Wenn ein Linux-Kernel das aktiviert Transparente Funktion für riesige Seiten, Redis verwendet Fork-Aufrufe. Es wird dann eine große Latenzstrafe für die Datenpersistenz auf der Festplatte geben.

Mit dieser Methode können Sie diese Funktion des Systemkernels deaktivieren:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Hinweis: Redis muss neu gestartet werden, damit es wirksam wird.

3. Überprüfen Sie, ob Redis von der Verwendung von Swap durch das System betroffen ist:

查找redis进程id：
redis-cli -p 6319 info|grep process_id
process_id:32139
查看redis进程的内存使用信息：
cd /proc/32139
查看该进程使用swap分区的统计信息，以不使用或只有少量的4kB为佳：
cat smaps | grep 'Swap:'
同时打印出内存映射和swap使用信息：查看那些较大的内存消耗是否引发了大的swap使用
cat smaps | egrep '^(Swap:Size)'

4. Verwenden Sie Redis Watchdog, um die Verzögerung zu lokalisieren: experimentell Funktion, bitte stellen Sie sicher, dass die Redis-Daten gesichert sind.

Redis software watchdog
该功能只能动态启用，使用以下命令：
CONFIG SET watchdog-period 500
注：redis会开始频繁监控自身的延时问题，并把问题输出到日志文件中去。
 
关闭watchdog：
CONFIG SET watchdog-period 0
 
注：打开watchdog功能，会对redis服务性能产生影响。

5. Informationen zum Redis-Latenzüberwachungs-Framework

Redis-Latenzüberwachungs-Framework

So aktivieren Sie das Redis-Überwachungsframework:

CONFIG SET latency-monitor-threshold 100

Standardmäßig hier In diesem Fall wird der Schwellenwert auf 0 gesetzt, wodurch die Redis-Überwachung deaktiviert wird. Tatsächlich verursacht die Aktivierung dieser Überwachungsfunktion nur sehr geringe Kosten für Redis. Für ein gut laufendes Redis besteht jedoch keine Notwendigkeit, diese Überwachungsfunktion zu aktivieren.

So verwenden Sie den LATENCY-Befehl

Das letzte Verzögerungsereignis anzeigen:

127.0.0.1:6319> latency latest
1) 1) "command"     #event name
   2) (integer) 1480865648     #发生时间
   3) (integer) 207     #耗时，毫秒
   4) (integer) 239     #从redis启动或上次latency reset以来，这种事件的最大延时记录

Die historischen Informationen des Verzögerungsereignisses anzeigen:

LATENCY HISTORY-Ereignis- name

Für ein bestimmtes Ereignis gibt der Befehl bis zu 160 Elemente zurück. Anwendungen möchten möglicherweise Rohdaten abrufen, um Überwachungen durchzuführen, Grafiken anzuzeigen usw.

127.0.0.1:6319> latency history command
  1) 1) (integer) 1480865710
     2) (integer) 207
  2) 1) (integer) 1480865711
     2) (integer) 217
  3) 1) (integer) 1480865712
     2) (integer) 198
  4) 1) (integer) 1480865713
     2) (integer) 226
  5) 1) (integer) 1480865714
     2) (integer) 224

Statistik auf Null zurücksetzen:

LATENCY RESET [event-name ... event-name]

Verzögerte Ereignisse in Form von Textdiagrammen anzeigen:

LATENCY GRAPH event-name
127.0.0.1:6379> latency graph command
command - high 500 ms, low 101 ms (all time high 500 ms)
--------------------------------------------------------------------------------
   #_
  _||
 _|||
_||||
 
11186
542ss
sss

Hinweis: Jede Spalte stellt ein verzögertes Ereignis dar; unten wird angezeigt, wie lange das Ereignis vor der aktuellen Zeit aufgetreten ist, z. B. 2 Minuten oder 38 Sekunden. Bei statistischen Ereignissen wird das Ereignis mit der minimalen Verzögerung als kurze Unterstreichung aufgezeichnet Das maximale Verzögerungsereignis wird von oben als A # ausgedrückt. Diese Zahl kann einen sich ändernden Trend verzögerter Ereignisse widerspiegeln.

LATENCY DOCTOR, intelligente Analyse und Vorschläge für Statistiken zu verzögerten Ereignissen:

127.0.0.1:6379> latency doctor
Dave, I have observed latency spikes in this Redis instance.
You don't mind talking about it, do you Dave?
1. command: 5 latency spikes (average 300ms, mean deviation 120ms,
  period 73.40 sec). Worst all time event 500ms.
I have a few advices for you:
- Your current Slow Log configuration only logs events that are
  slower than your configured latency monitor threshold. Please
  use 'CONFIG SET slowlog-log-slower-than 1000'.
- Check your Slow Log to understand what are the commands you are
  running which are too slow to execute. Please check
  http://redis.io/commands/slowlog for more information.
- Deleting, expiring or evicting (becaus

rrree

Weitere Redis-Kenntnisse finden Sie in der Spalte Redis-Tutorial auf der chinesischen PHP-Website.

Das obige ist der detaillierte Inhalt vonEinführung in Redis-Leistungsanalyse- und Überwachungslösungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!