摘要：一次由fork引發的時延抖動問題。
背景介紹
華為雲數據庫GaussDB(for Redis) 是一款基於計算存儲分離架構，兼容Redis生態的雲原生NoSQL數據庫；它依靠共享存儲池實現了強一致，支持持久化落盤存儲，保證數據的安全可靠。其核心特點是：存算分離、強一致、低成本、超大容量。
GaussDB(for Redis)服務團隊在支撐某客戶業務上雲的過程中，發現一次由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.排查抖動源：
1）由於故障的時間分布非常規律，首先排除定時任務的影響，主要包括：
- agent：和管控對接的周期性統計信息上報任務
- 內核：執行引擎（Redis協議解析）和存儲引擎（rocksdb）的周期性操作（包括rocskdb統計，wal清理等）
屏蔽上述2類定時任務后，抖動依然存在。
2）排除法未果后，決定回到正向定位的路上來。通過對數據訪問路徑增加分段耗時統計，最終發現抖動時刻內存操作（包括allocate、memcpy等）的耗時顯著變長；基本上長出來的時延，都是阻塞在了內存操作上。
（截圖為相關日志，單位是微秒）
3）既然定位到是系統級操作的抖動，那么下一步的思路就是捕獲抖動時刻系統是否有異常。我們采取的方法是，通過腳本定時抓取top信息，分析系統變化。運氣比較好，腳本部署后一下就抓到了一個關鍵信息：每次在抖動的時刻，系統中會出現一個frm-timer進程；該進程為GaussDB(for Redis)進程的子進程，且為瞬時進程，持續1-2s后退出。
4）為了確認該進程的影響，我們又抓取了perf信息，發現在該進程出現時刻，Kmalloc， memset_sse，memcopy_sse等內核系統調用增多。從上述信息推斷，frm-timer進程應該是被fork出來的，抖動源基本可鎖定在fork frm-timer這個動作上。
2.確定引發抖動的代碼：
1）分析frm-timer的來歷是下一步的關鍵。因為這個標識符不在我們的代碼中，所以就需要拉通給我們提供類庫的兄弟部門聯合分析了。經過大家聯合排查，確認frm-timer是日志庫liblog中的一個定時器處理線程。如果這個線程fork了一個匿名的子進程，就會復用父進程的線程名，表現為Redis進程創建出1個名為frm-timer的子進程的現象。
2）由於frm-timer負責處理liblog中所有模塊的定時器任務，究竟是哪個模塊觸發了上述fork？這里我們采取了一個比較巧妙的方法，我們在定時器處理邏輯中增加了一段代碼：如果處理耗時超過30ms，則調用std:: abort()退出，以生成core棧。
3）通過分析core棧，並結合代碼排查，最終確認引發抖動的代碼如下：
上述代碼是用來周期性歸檔日志的，它每5分鍾會執行1次 system系統調用來運行相關腳本，完成歸檔日志的操作。而Linux system系統調用的源碼如下，實際上是一個先fork子進程，再調用execl的過程。
4）分析至此，我們還需要回答最后一個問題：究竟是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的影響：
1）眾所周知，fork是Linux（嚴格說是POSIX接口）創建子進程的系統調用，歷史上看，主流觀點大多對其贊譽有加；但近年間隨着技術演進，也陸續出現了反對的聲音：有人認為fork是上個時代遺留的產物，在現代操作系統中已經過時，有很多害處。激進的觀點甚至認為它應該被徹底棄用。（參見附錄1,2）
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() 調用了]
https://www.infoq.cn/article/BYGiWI-fxHTNvSohEUNW
2.[Linux fork那些隱藏的開銷]
https://www.mdeditor.tw/pl/29L0
3.[Redis官方文檔]
https://redis.io/topics/latency
4.[Redis的一些坑]
https://www.jianshu.com/p/03df6fd516eb
5.[Redis 常見問題之-fork操作]
https://blog.csdn.net/longgeqiaojie304/article/details/89407214
6.[GaussDB(for Redis)官網鏈接]
https://www.huaweicloud.com/product/gaussdbforredis.html
本文作者：華為雲數據庫GaussDB(for Redis)團隊