摘要：高斯Redis，徹底解決原生Redis的fork抖動問題!

背景介紹

在一次支撐客戶業務上云的過程中，發現一次由fork引發的時延抖動問題，通過詳細探究了fork這個系統調用的性能影響，并且在最新的GaussDB(for Redis)版本已解決了這個抖動問題，清零了內部的fork使用，與原生Redis相比，徹底解決了fork的性能隱患。

問題焦點

· 華為云GaussDB(for Redis)服務在某客戶上云線調測過程中發現，系統上量后規律性的出現每5分鐘1次的時延抖動問題。

· 華為云GaussDB(for Redis)團隊經過攻關，最終確認抖動原因是fork導致并解決了這個問題。而fork是開源Redis的一個重要依賴，希望通過本文的分享，能夠幫助大家在使用開源Redis的時候，充分認識fork的影響，從而選擇更優的方案。

問題現象

客戶業務接入GaussDB(for Redis)壓測發現，每5分鐘系統出現一次規律性的時延抖動：

· 正常情況消息時延在1-3ms，抖動時刻時延達到300ms左右。

· 通常是壓測一段時間后開始出現抖動；抖動一旦出現后就非常規律的保持在每5分鐘1次；每次抖動的持續時長在10ms以內。

下圖是從系統慢日志中捕獲到的發生抖動的消息樣例(對敏感信息進行了遮掩)：

問題分析

1)排查抖動源：

· 由于故障的時間分布非常規律，首先排除定時任務的影響，主要包括：

· agent：和管控對接的周期性統計信息上報任務

· 內核：執行引擎(Redis協議解析)和存儲引擎(rocksdb)的周期性操作(包括rocskdb統計，wal清理等)

屏蔽上述2類定時任務后，抖動依然存在。

· 排除法未果后，決定回到正向定位的路上來。通過對數據訪問路徑增加分段耗時統計，最終發現抖動時刻內存操作(包括allocate、memcpy等)的耗時顯著變長；基本上長出來的時延，都是阻塞在了內存操作上。

(截圖為相關日志，單位是微秒)

· 既然定位到是系統級操作的抖動，那么下一步的思路就是捕獲抖動時刻系統是否有異常。我們采取的方法是，通過腳本定時抓取top信息，分析系統變化。運氣比較好，腳本部署后一下就抓到了一個關鍵信息：每次在抖動的時刻，系統中會出現一個frm-timer進程；該進程為GaussDB(for Redis)進程的子進程，且為瞬時進程，持續1-2s后退出。

· 為了確認該進程的影響，我們又抓取了perf信息，發現在該進程出現時刻，Kmalloc， memset_sse，memcopy_sse等內核系統調用增多。從上述信息推斷，frm-timer進程應該是被fork出來的，抖動源基本可鎖定在fork frm-timer這個動作上。

2)確定引發抖動的代碼：

· 分析frm-timer的來歷是下一步的關鍵。因為這個標識符不在我們的代碼中，所以就需要拉通給我們提供類庫的兄弟部門聯合分析了。經過大家聯合排查，確認frm-timer是日志庫liblog中的一個定時器處理線程。如果這個線程fork了一個匿名的子進程，就會復用父進程的線程名，表現為Redis進程創建出1個名為frm-timer的子進程的現象。

· 由于frm-timer負責處理liblog中所有模塊的定時器任務，究竟是哪個模塊觸發了上述fork？這里我們采取了一個比較巧妙的方法，我們在定時器處理邏輯中增加了一段代碼：如果處理耗時超過30ms，則調用std:: abort()退出，以生成core棧。

· 通過分析core棧，并結合代碼排查，最終確認引發抖動的代碼如下：

上述代碼是用來周期性歸檔日志的，它每5分鐘會執行1次 system系統調用來運行相關腳本，完成歸檔日志的操作。而Linux system系統調用的源碼如下，實際上是一個先fork子進程，再調用execl的過程。

· 分析至此，我們還需要回答最后一個問題：究竟是fork導致的抖動，還是腳本內容導致的抖動？為此，我們設計了一組測試用例：

· 用例1：將腳本內容改為最簡單的echo操作

· 用例2：在Redis進程里模擬1個類似frm-timer的線程，通過命令觸發該線程執行fork操作

· 用例3：在Redis進程里模擬1個類似frm-timer的線程，通過命令觸發該線程執行先fork，再excel的操作

· 用例4：在Redis進程里模擬1個類似frm-timer的線程，通過命令觸發該線程執行system的操作

· 用例5：在Redis進程里模擬1個類似frm-timer的線程，通過命令觸發該線程執行先vfork，再excel的操作

最終的驗證結果：

· 用例1：有抖動。

· 用例2：有抖動。

· 用例3：有抖動。

· 用例4：有抖動。

· 用例5：無抖動。

用例1結果表明抖動和腳本內容無關；用例2、3、4的結果表明調用system引發抖動的根因是因為其中執行了fork操作；用例5的結果進一步佐證了抖動的根因就是因為fork操作。最終的故障原因示意圖如下：

3)進一步探究fork的影響：

· 眾所周知，fork是Linux(嚴格說是POSIX接口)創建子進程的系統調用，歷史上看，主流觀點大多對其贊譽有加；但近年間隨著技術演進，也陸續出現了反對的聲音：有人認為fork是上個時代遺留的產物，在現代操作系統中已經過時，有很多害處。激進的觀點甚至認為它應該被徹底棄用。(參見附錄1,2)

· fork當前被詬病的主要問題之一是它的性能。大家對fork通常的理解是其采用copy-on-wirte寫時復制策略，因此對其的性能影響不甚敏感。但實際上，雖然fork時可共享的數據內容不需要復制，但其相關的內核數據結構(包括頁目錄、頁表、vm_area_struc等)的復制開銷也是不容忽視的。附錄1、2中的文章對fork開銷有詳細介紹，我們這回遇到的問題也是一個鮮活的案例：對于Redis這樣的時延敏感型應用，1次fork就可能導致消息時延出現100倍的抖動，這對于應用來說無疑是不可接受的。

4)原生Redis的fork問題：

4.1 原生Redis同樣被fork問題困擾(參見附錄3，4，5)，具體包括如下場景：

1)數據備份

備份時需要生成RDB文件，因此Redis需要觸發一次fork。

2)主從同步

全量復制場景(包括初次復制或其他堆積嚴重的情況)，主節點需要產生RDB文件來加速同步，同樣需要觸發fork。

3)AOF重寫

當AOF文件較大，需要合并重寫時，也會產生一次fork。

4.2 上述fork問題對原生Redis的影響如下：

1)業務抖動

原生Redis采用單線程架構，如果在電商大促、熱點事件等業務高峰時發生上述fork，會導致Redis阻塞，進而對業務造成雪崩的影響。

2)內存利用率只有50%

Fork時子進程需要拷貝父進程的內存空間，雖然是COW，但也要預留足夠空間以防不測，因此內存利用率只有50%，也使得成本高了一倍。

3)容量規模影響

為減小fork的影響，生產環境上原生Redis單個進程的最大內存量，通常控制在5G以內，導致原生Redis實例的容量大大受限，無法支撐海量數據。

解決方法修改日志庫liblog中的周期性歸檔邏輯，不再fork子進程。

系統排查并整改GaussDB(for Redis)代碼(包括使用的類庫代碼)中的fork調用。

最終排查結果，實際只有本次的這個問題點涉及fork。當前修改后即可確保GaussDB(for Redis)的時延保持穩定，不再受fork性能影響。

注：GaussDB(for Redis)由華為云基于存算分離架構自主開發，因此不存在原生Redis的fork調用的場景。

總結

本文通過分析GaussDB(for Redis)的一次由fork引發的時延抖動問題，探究了fork這個系統調用的性能影響。最新的GaussDB(for Redis)版本已解決了這個抖動問題，并清零了內部的fork使用，與原生Redis相比，徹底解決了fork的性能隱患。希望通過這個問題的分析，能夠帶給大家一些啟發，方便大家更好的選型。

附：

1.[是時候淘汰對操作系統的 fork() 調用了]

2.[Linux fork那些隱藏的開銷]

3.[Redis官方文檔]

4.[Redis的一些坑]

5.[Redis 常見問題之-fork操作]

6.[GaussDB(for Redis)官網鏈接]

本文分享自華為云社區《華為云PB級數據庫GaussDB(for Redis)揭秘第三期：一場由fork引發的超時，讓我們重新探討了Redis的抖動問題》，原文作者：高斯Redis官方博客 。

總結

以上是生活随笔為你收集整理的linux date抖动,一场由fork引发的超时，让我们重新探讨了Redis的抖动问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。