詳細(xì)講解redis性能與監(jiān)控方案

這篇文章主要為大家詳細(xì)介紹了redis性能與監(jiān)控方案，文中示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下。

我們提供的服務(wù)有：成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、堯都ssl等。為1000多家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的堯都網(wǎng)站制作公司

1、redis slowlog分析

SLOWLOG subcommand [argument]

以下為redis.conf的慢查詢配置參數(shù)：

slowlog-log-slower-than 10000     #查詢時(shí)間超過10ms的會(huì)被記錄
slowlog-max-len 128     #最多記錄128個(gè)慢查詢

以上參數(shù)可以在redis中動(dòng)態(tài)查詢或設(shè)置：使用config get 與config set命令

讀取慢查詢：可以獲取指定幾條的慢查詢

127.0.0.1:6320> slowlog get 1
 1) 1) (integer) 394689     #slowlog的唯一編號
    2) (integer) 1480851711     #此次slowlog事件的發(fā)生時(shí)間
    3) (integer) 10639     #耗時(shí)
    4) 1) "HGET"     #slowlog事件所對應(yīng)的redis 命令
       2) "hash:submit_sent_150004"
       3) "15000429648122734363745165312"

重置slowlog統(tǒng)計(jì)數(shù)據(jù)：

SLOWLOG RESET

redis slow commands分析：

1、redis使用單線程處理客戶端的請求，結(jié)果是，當(dāng)請求緩慢服務(wù)時(shí)，所有其他客戶端將等待這個(gè)請求被服務(wù)。如果需要執(zhí)行很多的slow commands，建議把slow queries放到redis slave上去執(zhí)行。

2、關(guān)于keys命令：執(zhí)行慢速命令所產(chǎn)生的非常常見的延遲源是在生產(chǎn)環(huán)境中使用KEYS命令。如Redis文檔中所述，KEYS應(yīng)該只用于調(diào)試目的。

redis2.8以后為查詢大集合而引入了新的命令，請檢查SCAN，SSCAN，HSCAN和ZSCAN命令以獲取更多信息。

SCAN迭代當(dāng)前選定的Redis數(shù)據(jù)庫中的鍵集。
SSCAN迭代sets集合類型的元素。
HSCAN迭代哈希類型及其關(guān)聯(lián)值的字段。
ZSCAN迭代排序集類型的元素及其相關(guān)聯(lián)的分?jǐn)?shù)。

由于這些命令允許增量迭代，每次調(diào)用僅返回少量元素，所以它們可以在生產(chǎn)中使用，而無需像KEYS或SMEMBERS這樣的命令的缺點(diǎn)，當(dāng)調(diào)用大集合的鍵或元素時(shí)可能會(huì)阻止服務(wù)器長時(shí)間（甚至幾秒鐘）。

2、SCAN，SSCAN，HSCAN和ZSCAN命令的使用方法

SCAN是基于游標(biāo)的迭代器。這意味著在每次調(diào)用命令時(shí)，服務(wù)器返回一個(gè)更新的游標(biāo)，用戶需要在下一次調(diào)用中用作游標(biāo)參數(shù)。

當(dāng)游標(biāo)設(shè)置為0時(shí)，迭代開始，并且當(dāng)服務(wù)器返回的游標(biāo)為0時(shí)終止迭代。以下是SCAN迭代的示例：

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"

開始游標(biāo)值為0的迭代，并調(diào)用SCAN，直到返回的游標(biāo)再次為0，稱為完全迭代。

scan的count選項(xiàng)：指定輸出的數(shù)量

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"

scan的match選項(xiàng)：類似于keys命令按模式匹配，只需在SCAN命令末尾附加MATCH 參數(shù)

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*     #查找匹配的數(shù)據(jù)并返回15個(gè)
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"

sscan查詢sets集合的方法：

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>

hscan查詢hash集合的方法：

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"

當(dāng)一個(gè)Linux內(nèi)核啟用了透明巨頁功能時(shí)，Redis在使用fork調(diào)用之后會(huì)產(chǎn)生大的延遲代價(jià)，以便在磁盤進(jìn)行數(shù)據(jù)持久化。

可以使用這個(gè)方法關(guān)閉系統(tǒng)內(nèi)核的該特性：

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

注：需重啟redis才能生效。

3、檢查redis是否受到系統(tǒng)使用swap的影響：

查找redis進(jìn)程id：
redis-cli -p 6319 info|grep process_id
process_id:32139
查看redis進(jìn)程的內(nèi)存使用信息：
cd /proc/32139
查看該進(jìn)程使用swap分區(qū)的統(tǒng)計(jì)信息，以不使用或只有少量的4kB為佳：
cat smaps | grep 'Swap:'
同時(shí)打印出內(nèi)存映射和swap使用信息：查看那些較大的內(nèi)存消耗是否引發(fā)了大的swap使用
cat smaps | egrep '^(Swap:Size)'

4、使用redis watchdog定位延時(shí)：實(shí)驗(yàn)功能，請確保redis數(shù)據(jù)已備份。

Redis software watchdog
該功能只能動(dòng)態(tài)啟用，使用以下命令：
CONFIG SET watchdog-period 500
注：redis會(huì)開始頻繁監(jiān)控自身的延時(shí)問題，并把問題輸出到日志文件中去。
 
關(guān)閉watchdog：
CONFIG SET watchdog-period 0
 
注：打開watchdog功能，會(huì)對redis服務(wù)性能產(chǎn)生影響。

5、關(guān)于redis的延時(shí)監(jiān)控框架

Redis latency monitoring framework

啟用redis監(jiān)控框架的方法：

CONFIG SET latency-monitor-threshold 100

默認(rèn)情況下，閾值設(shè)置為0，即禁用redis監(jiān)控。實(shí)際上啟用該監(jiān)控功能，對redis所增加的成本很少。不過對于一個(gè)運(yùn)行良好的redis，是沒有必要打開該監(jiān)控功能。

LATENCY命令的使用方法

查看最新的延時(shí)事件：

127.0.0.1:6319> latency latest
1) 1) "command"     #event name
   2) (integer) 1480865648     #發(fā)生時(shí)間
   3) (integer) 207     #耗時(shí)，毫秒
   4) (integer) 239     #從redis啟動(dòng)或上次latency reset以來，這種事件的最大延時(shí)記錄

查看延時(shí)事件的歷史信息：

LATENCY HISTORY event-name

對于給定事件，命令將返回最多160個(gè)元素。應(yīng)用程序可能想要獲取原始數(shù)據(jù)以便執(zhí)行監(jiān)視，顯示圖形等。

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

統(tǒng)計(jì)數(shù)據(jù)歸零：

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

以文本圖表形式展示延時(shí)事件：

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

注：每一列表示一個(gè)遲時(shí)事件；下方顯示的是該事件發(fā)生在當(dāng)前時(shí)間之前多久，如2m或38s；統(tǒng)計(jì)事件中最小延時(shí)事件記為一個(gè)短下劃線，最大延時(shí)事件表示為高高在上的一個(gè)#。該圖可以體現(xiàn)出延時(shí)事件的一個(gè)變化趨勢。

LATENCY DOCTOR，延時(shí)事件統(tǒng)計(jì)信息的智能分析與建議：

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

127.0.0.1:6320> latency doctor
I have a few advices for you:
- I detected a non zero amount of anonymous huge pages used by your process. This creates very serious latency events in different conditions, especially 
when Redis is persisting on disk. To disable THP support use the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled', make sure to also 
add it into /etc/rc.local so that the command will be executed again after a reboot. Note that even if you have already disabled THP, you still need to
 restart the Redis process to get rid of the huge pages already created.

關(guān)于redis性能與監(jiān)控方案就分享到這里了，當(dāng)然并不止以上和大家分析的辦法，不過小編可以保證其準(zhǔn)確性是絕對沒問題的。希望以上內(nèi)容可以對大家有一定的參考價(jià)值，可以學(xué)以致用。如果喜歡本篇文章，不妨把它分享出去讓更多的人看到。

網(wǎng)站欄目：詳細(xì)講解redis性能與監(jiān)控方案
網(wǎng)站網(wǎng)址：http://www.xueling.net.cn/article/piciii.html

老熟女激烈的高潮_日韩一级黄色录像_亚洲1区2区3区视频_精品少妇一区二区三区在线播放_国产欧美日产久久_午夜福利精品导航凹凸

重慶分公司，新征程啟航

詳細(xì)講解redis性能與監(jiān)控方案

其他資訊