您好,登錄后才能下訂單哦!
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進行排查。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。