1. 程式人生 > >redis阻塞分析

redis阻塞分析

         redis是經典的單執行緒架構,所有的讀寫操作都是在一個主執行緒中完成的。當redis處於高併發情況時,如果出現阻塞,哪怕是很短的時間,對於應用來說都相當嚴重,會出現大量的超時問題,應用出問題。

1.  redis的阻塞主要包括兩方面:

   1.1 內在原因:不合理使用API或資料結構、CPU飽和持久化阻塞

   1.2 外在原因:CPU競爭、記憶體交換、網路問題


     1.1內在原因:

          1.1.1:如何發現慢查詢:slowlog get [N]  選型:N,可選,代表獲取的日誌條數

          1.1.2:如何發現大物件:redis-cli -h {ip} -p {port} --bigkeys

          1.1.3:CPU飽和問題:單執行緒Redis 處理命令時只能使用一個CPU,而CPU飽和是指Redis把單核CPU使用率跑到接近100%。CPU飽和導致Redis無法處理更多命令,嚴重影響吞吐和應用方的穩定。

     如何發現CPU飽和:redis-cli -h {ip} -p {port} --stat

          1.1.4:持久化相關阻塞:

                 a.fork阻塞: fork操作本身耗時過長,會導致主執行緒阻塞。
          通過info stats中的latest_fork_usec指標確定(單位為微秒),表示最近一次fork操作耗時,如果耗時很大,比如超過1秒,則需要做優化調整,比如不使用過大記憶體例項,或者規避fork緩慢的xen虛擬機器。

                b.AOF刷盤阻塞:當我們開啟AOF持久化功能時,檔案刷盤的方式一般採用每秒一次,後臺執行緒每秒對AOF檔案做fsync操作。當硬碟壓力過大時,fsync操作需要等待,直到寫入完成。如果主執行緒發現距離上一次的fsync成功超過2秒,為了資料安全性它會阻塞直到後臺執行緒執行fsync操作完成。這種阻塞行為主要是硬碟壓力引起。後臺日誌會出現如下資訊:

Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOFbuffer without waiting for fsync to complete, this may slow down Redis.

     1.2 外在原因:

          1.2.1:CPU競爭:redis是經典的CPU密集型應用,不建議和其它的程式一起使用。可以使用top命令都為問題;

          1.2.2:繫結CPU:優化把Redis繫結到CPU上,降低CPU頻繁上下文切換。

                   注意:對於開啟了持久化或參與複製的主節點不建議繫結CPU,防止父程序與子程序將產生激烈CPU競爭,影響Redis穩定性。

          1.2.3:記憶體交行:定位記憶體交換方法:

                   a.查詢redis程序號:redis-cli -p 6384 info server |grep process_id

                   b.根據程序號查詢記憶體交換資訊:cat /proc/xxxx/smaps |grep Swap

                   c.如果交換都是0kb或者偶爾4kb屬於正常現象

                   d. 降低系統使用swap優先順序: 修改swappiness

          1.2.4:網路問題:

                   a. Redis連線拒絕:Redis通過maxclients引數控制客戶端最大連線數,預設10000。檢視info stats的rejected_connections統計指標展示被拒絕的數量。客戶端訪問儘量採用長連線或者連線池方    式。程序限制優化:設定ulimit -n 65535 防止 Too many Open files
                   b.backlog佇列溢位:系統預設backlog為128,優化:使用echo 512>/proc/sys/net/core/somaxconn修改系統預設引數,如果懷疑是backlog佇列溢位,佇列溢位統計:

                      netstat-s|grepoverflowed,檢視是否有持續增長的連線拒絕情況。

                   c.網路延時:網路延時統計:
                                   redis-cli -h {host} -p {port} --latency
                                  分別統計:最小值、最大值、平均值、取樣次數
                                  網路延時一般發生在跨機房部署
                   d.網絡卡軟中斷:單個網絡卡佇列只能使用一個CPU,高併發下網絡卡資料集中在一個CPU下,導致無法利用多核CPU。網絡卡軟中斷瓶頸一般出現在網路高流量吞吐場景,top的si指標過高。

                      使用top 命令,按下1進行排查。