2. 程式人生 > >redis效能分析與監控方案

redis效能分析與監控方案

阿新 • • 發佈：2019-01-16
1、redis slowlog分析
2、SCAN，SSCAN，HSCAN和ZSCAN命令的使用方法
3、檢查redis是否受到系統使用swap的影響
4、使用redis watchdog定位延時
5、關於redis的延時監控框架

redis官網資料參見這裡：https://redis.io/topics/latency-monitor 1、redis slowlog分析 SLOWLOG subcommand [argument] 以下為redis.conf的慢查詢配置引數： 
slowlog-log-slower-than 10000     #查詢時間超過10ms的會被記錄
slowlog-max-len 128     #最多記錄128個慢查詢
以上引數可以在redis中動態查詢或設定：使用config get 與config set命令 讀取慢查詢：可以獲取指定幾條的慢查詢 
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統計資料： 
SLOWLOG RESET
redis slow commands分析：
  1. redis使用單執行緒處理客戶端的請求，結果是，當請求緩慢服務時，所有其他客戶端將等待這個請求被服務。如果需要執行很多的slow commands，建議把slow queries放到redis slave上去執行。
  2. 關於keys命令：執行慢速命令所產生的非常常見的延遲源是在生產環境中使用KEYS命令。 如Redis文件中所述，KEYS應該只用於除錯目的。
redis2.8以後為查詢大集合而引入了新的命令，請檢查SCAN，SSCAN，HSCAN和ZSCAN命令以獲取更多資訊。
  • SCAN迭代當前選定的Redis資料庫中的鍵集。
  • SSCAN迭代sets集合型別的元素。
  • HSCAN迭代雜湊型別及其關聯值的欄位。
  • ZSCAN迭代排序集型別的元素及其相關聯的分數。
由於這些命令允許增量迭代，每次呼叫僅返回少量元素，所以它們可以在生產中使用，而無需像KEYS或SMEMBERS這樣的命令的缺點，當呼叫大集合的鍵或元素時可能會阻止伺服器長時間（甚至幾秒鐘） 。 2、SCAN，SSCAN，HSCAN和ZSCAN命令的使用方法 SCAN是基於遊標的迭代器。 這意味著在每次呼叫命令時，伺服器返回一個更新的遊標，使用者需要在下一次呼叫中用作遊標引數。 當遊標設定為0時，迭代開始，並且當伺服器返回的遊標為0時終止迭代。以下是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"
開始遊標值為0的迭代，並呼叫SCAN，直到返回的遊標再次為0，稱為完全迭代。 scan的count選項：指定輸出的數量 
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選項：類似於keys命令按模式匹配，只需在SCAN命令末尾附加MATCH <pattern>引數 
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"
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"
當一個Linux核心啟用了透明巨頁功能時，Redis在使用fork呼叫之後會產生大的延遲代價，以便在磁碟進行資料持久化。 可以使用這個方法關閉系統核心的該特性：
echo never > /sys/kernel/mm/transparent_hugepage/enabled
注：需重啟redis才能生效。

 3、檢查redis是否受到系統使用swap的影響： 
查詢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、使用redis watchdog定位延時：實驗功能，請確保redis資料已備份。 
Redis software watchdog
該功能只能動態啟用，使用以下命令：
CONFIG SET watchdog-period 500
注：redis會開始頻繁監控自身的延時問題，並把問題輸出到日誌檔案中去。

關閉watchdog：
CONFIG SET watchdog-period 0

注：開啟watchdog功能，會對redis服務效能產生影響。
5、關於redis的延時監控框架 Redis latency monitoring framework 啟用redis監控框架的方法： 
CONFIG SET latency-monitor-threshold 100
預設情況下，閾值設定為0，即禁用redis監控。實際上啟用該監控功能，對redis所增加的成本很少。不過對於一個執行良好的redis，是沒有必要開啟該監控功能。 LATENCY命令的使用方法 檢視最新的延時事件： 
127.0.0.1:6319> latency latest
1) 1) "command"     #event name
   2) (integer) 1480865648     #發生時間
   3) (integer) 207     #耗時，毫秒
   4) (integer) 239     #從redis啟動或上次latency reset以來，這種事件的最大延時記錄
檢視延時事件的歷史資訊： LATENCY HISTORY event-name 對於給定事件，命令將返回最多160個元素。 應用程式可能想要獲取原始資料以便執行監視，顯示圖形等。 
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
統計資料歸零： LATENCY RESET [event-name ... event-name] 以文字圖表形式展示延時事件： 
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
注：每一列表示一個遲時事件；下方顯示的是該事件發生在當前時間之前多久，如2m或38s；統計事件中最小延時事件記為一個短下劃線，最大延時事件表示為高高在上的一個#。該圖可以體現出延時事件的一個變化趨勢。 LATENCY DOCTOR，延時事件統計資訊的智慧分析與建議： 
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.

相關推薦

redis效能分析與監控方案

1、redis slowlog分析2、SCAN，SSCAN，HSCAN和ZSCAN命令的使用方法3、檢查redis是否受到系統使用swap的影響4、使用redis watchdog定位延時5、關於redis的延時監控框架 redis官網資料參見這裡：https://red

效能分析與優化方案

效能問題分類1、渲染問題：過度繪製、佈局冗雜2、記憶體問題：記憶體浪費（記憶體管理）、記憶體洩漏3、功耗問題：耗電效能優化工具以下優化工具在下面文章中具體介紹使用方法。1、手機開發者選項：除錯GPU過度繪製、啟用嚴格模式、顯示CPU使用情況、GPU呈現模式分析、顯示所有"應用程式無響應"。（小米手機開發開發者

JavaScript 啟動效能瓶頸分析與解決方案

在 Web 開發中，隨著需求的增加與程式碼庫的擴張，我們最終釋出的 Web 頁面也逐漸膨脹。不過這種膨脹遠不止意味著佔據更多的傳輸頻寬，其還意味著使用者瀏覽網頁時可能更差勁的效能體驗。瀏覽器在下載完某個頁面依賴的指令碼之後，其還需要經過語法分析、解釋與執行這些步驟。而本文則會

Android效能全面分析與優化方案研究

效能優化是一個持續的過程，要多種手段，一點一點優化，一般是優化影響比較大頭的，再逐步優化小頭的，

Android 系統性能優化（30）---Android效能全面分析與優化方案研究

5.1、渲染問題先來看看造成應用UI卡頓的常見原因都有哪些？1、人為在UI執行緒中做輕微耗時操作，導致UI執行緒卡頓；2、佈局Layout過於複雜，無法在16ms內完成渲染；3、同一時間動畫執行的次數過多，導致CPU或GPU負載過重；4、View過度繪製，導致某些畫素在同一幀時間內被繪製多次，從而使CPU或G

Java內部類持有外部類的引用詳細分析與解決方案

調用 lai urn star keyword inner android get sta 在Java中內部類的定義與使用一般為成員內部類與匿名內部類，他們的對象都會隱式持有外部類對象的引用，影響外部類對象的回收。 GC只會回收沒有被引用或者根集不可到達的對象（取決於GC算

第五次作業——python效能分析與幾個問題（個人作業）

結合 撰寫 porting tin 設計實現 cti personal 設計文檔 hub 第五次作業——效能分析與幾個問題（個人作業） 前言 閱讀了大家對於本課程的目標和規劃之後，想必很多同學都躍躍欲試，迫不及待想要提高自身實踐能力，那麽就從第一個個人項目開始吧，題目要求見

MySQL服務器 IO 100%的分析與優化方案

文件 %u mysq 希望 影響 前言 文章 興趣 排查 前言 壓力測試過程中，如果因為資源使用瓶頸等問題引發最直接性能問題是業務交易響應時間偏大，TPS逐漸降低等。而問題定位分析通常情況下，最優先排查的是監控服務器資源利用率，例如先用TOP 或者nmon等查看CPU、內存

OpenCV學習筆記（30）KAZE 演算法原理與原始碼分析（四）KAZE特徵的效能分析與比較

      KAZE系列筆記： 1.  OpenCV學習筆記（27）KAZE 演算法原理與原始碼分析（一）非線性擴散濾波 2.  OpenCV學習筆記（28）KAZE 演算法原理與原始碼分析（二）非線性尺度空間構

效能分析與提升

圖形化工具進行效能分析 此篇部落格主要談談用圖形化工具分析與優化python程式碼，雖然我們的工程不是很大，但符合比較大吧，功能有字母頻率統計、詞頻統計、支援stopword、動詞時態歸一化、動介短語頻率統計。我以 step0-輸出某個英文文字檔案中 26 字母出現的頻率，由高到低

效能分析與程式碼覆蓋率測試

效能分析 對程式碼優化的前提是需要了解效能瓶頸在什麼地方，程式執行的主要時間是消耗在哪裡，對於比較複雜的程式碼可以藉助一些工具來定位，python 內建了豐富的效能分析工具，如 profile,cProfile 與 hotshot 等。其中 Profiler 是 python 自帶的一組程式，能

redis原始碼分析與思考（十九）——AOF持久化

    為了解決持久化檔案很龐大以及會阻塞伺服器的 情況，redis提出一種新的持久化方案：AOF持久化。AOF持久化是redis儲存資料的另外一種方式，全稱Append Only File，與RDB持久化不同的是，AOF持久化是隻儲存從客戶端鍵入

redis原始碼分析與思考（十八）——RDB持久化

    redis是一個鍵值對的資料庫伺服器，伺服器中包含著若干個非空的資料庫，每個非空資料庫裡又包含著若干個鍵值對。因為redis是一個基於記憶體存貯的資料庫，他將自己所存的資料存於記憶體中，如果不將這些資料及時的儲存在硬碟中，當電腦關機或者進行

redis原始碼分析與思考（十七）——有序集合型別的命令實現(t_zset.c)

    有序集合是集合的延伸，它儲存著集合元素的不可重複性，但不同的是，它是有序的，它利用每一個元素的分數來作為有序集合的排序依據，現在列出有序集合的命令： 有序集合命令 命令 對應操作 時

redis原始碼分析與思考（十六）——集合型別的命令實現(t_set.c)

    集合型別是用來儲存多個字串的，與列表型別不一樣，集合中不允許有重複的元素，也不能以索引的方式來通過下標獲取值，集合中的元素還是無序的。在普通的集合上增刪查改外，集合型別還實現了多個集合的取交集、並集、差集，集合的命令如下表所示： 集合命

redis原始碼分析與思考（十五）——雜湊型別的命令實現(t_hash.c)

    雜湊型別又叫做字典，在redis中，雜湊型別本身是一個鍵值對，而雜湊型別裡面也存貯著鍵值對，其對應關係是，每個雜湊型別的值對應著一個鍵值對或多對鍵值對，如圖所示： 雜湊型別命令 命令 對應操

redis原始碼分析與思考（十四）——列表型別的命令實現(t_list.c)

    列表型別是用來存貯多個字串物件的結構。一個列表可以存貯232-1個元素，可以對列表兩端進行插入(push)、彈出(pop)，還可以獲取指定範圍內的元素列表、獲取指定索引的元素等等，它可以靈活的充當棧和佇列的角色。下面列出列表的命令： 列

redis原始碼分析與思考（十三）——字串型別的命令實現(t_string.c)

    在對字串操作的命令中，主要有增加刪查該、批處理操作以及編碼的轉換命令，現在列出對字串物件操作的主要常用命令： 常用命令表 命令 對應操作 時間複雜度

Syslog日誌分析與監控

Syslog日誌分析與監控 網路管理工具應同時具備主動監控和被動監控能力。主動監控是指主動保持網路正常執行，即不間斷掃描網路，預防宕機。被動監控是指具備強大的排除故障機制，當發生網路故障時，分析解決。 Syslog監控是一個非常優秀的被動監控機制，OpManager提供基於規則 的方

客戶端網路切換導致應用退回登陸前介面 的故障分析與解決方案

故障現象： 使用者使用手機銀行客戶端登入，客戶端處於登入狀態，由WiFi網路切換為手機4G網路，導致手機銀行直接退回到登入前狀態，伺服器日誌顯示該使用者在登入期間出現兩個不同地點的IP。 故障分析： 網路架構如圖所示，當省內某使用者使用聯通WiFi登入手機銀行後，F5將請求轉發到