遊戲 Lag 白皮書 › L12 資料庫
Redis 慢指令 Redis blocking commands (single-threaded)
原因 ID db-redis-block · 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（DB 基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
Redis 一次只處理一個指令，因此一個慢指令就會擋住後面所有的請求。
為什麼 營運中用 KEYS 搜尋全部 key，或一次讀取、刪除含數百萬個元素的排行榜或清單 → 於是 在該指令結束前，其他所有請求都要等待（數十 ms～數秒） → 畫面上 使用 session、排行榜、快取的功能同時頓一下，登入變慢
- 症狀
- 定格, 輸入延遲, 連不上／無限讀取
- 因素
- 停滯, 延遲
- 誰會遇到
- 整個伺服器, 只有特定功能
- 何時
- 偶爾隨機發生, 固定週期
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（DB 基礎設施）
- 遊戲開發團隊要做的事
- 用 SCAN 取代 KEYS、拆分大型 key、刪除改用 UNLINK（背景刪除）、分散集中在同一秒的過期時間。
- 基礎設施團隊要做的事
- 監看慢指令紀錄（SLOWLOG）、在正式環境伺服器上封鎖 KEYS 等危險指令、定期檢查大型 key、關閉 THP 並保留 fork 所需的記憶體餘裕、RDB 與 AOF 持久化改在複本上進行。
- 數值參考
- 一般指令不到 1ms。一次處理數百萬個元素時，有時要花數百 ms 到數秒。
- 圖表上
- 偶爾隨機飆高 · Redis 回應延遲、慢指令數
- 查看位置
- 用 SLOWLOG GET 看超過 slowlog-log-slower-than 的指令；用 CONFIG SET latency-monitor-threshold 開啟延遲監控（預設關閉）後，以 LATENCY LATEST、LATENCY DOCTOR 看 fork、expire-cycle 等各事件的延遲。也用 INFO 的 latest_fork_usec 與 redis-cli --bigkeys 確認 fork 時間與大型 key
- 符合的跡象
- 停住的時間點，SLOWLOG 中留有 KEYS 或一次處理整個大型 key 的指令，或 LATENCY 在同一時間記錄到數十 ms 以上的 fork、expire-cycle 事件
- 不符合的跡象
- SLOWLOG、LATENCY 都是空的，只有從遊戲伺服器端看很慢時，是網路或遊戲伺服器內部的等待（SLOWLOG 只量指令執行時間，不含與用戶端往來的時間）
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 深入了解
- 為了建立持久化檔案（RDB 快照）或重寫 AOF 而複製處理程序（fork）的瞬間也會停住。在現今的伺服器上，每 1GB 記憶體約需 10ms，30GB 就約 300ms。開啟大分頁（THP）時，fork 之後每次寫入都要整個複製一個大分頁（copy-on-write），暫停時間與記憶體用量都會大增，所以通常會關閉 THP，並保留充足的記憶體餘裕。同一秒內過期的 key 非常多時，Redis 也會為了刪除它們而短暫停住。
出處
- Diagnosing latency issues Redis
由單一執行緒依序處理請求，慢指令會擋住後面所有請求；用 SCAN 取代 KEYS；fork 在實體伺服器與新型 VM 上實測每 1GB 約 9～13ms；THP 會因 fork 後的複製造成延遲與記憶體暴增；同一秒大量過期時會停住 - KEYS Redis
在正式環境中務必極度謹慎使用，在大型 DB 上可能嚴重拖垮效能（入門級筆電上 100 萬個 key 需 40ms） - UNLINK Redis
立即移除 key、在其他執行緒回收記憶體的非同步刪除 - SLOWLOG Redis
記錄超過 slowlog-log-slower-than 之指令的慢指令 log，執行時間不含與用戶端往來的 I/O - Redis latency monitoring Redis
latency-monitor-threshold 預設為 0（關閉）；LATENCY LATEST、LATENCY DOCTOR；記錄 fork、expire-cycle 等各事件的延遲 - INFO Redis
latest_fork_usec：最後一次 fork 所花的時間（微秒） - Redis CLI Redis
--bigkeys：掃描 keyspace 找出大型 key
相關原因
同一層：L12 資料庫
同一症狀（定格）在其他層的原因
查看含圖解與實驗的完整版卡片