華為云企業級Redis揭秘第三期：一場由fork引發的超時，讓我們重新探討了Redis抖動問題

【最新活動】企業級Redis專場熱銷中！首月免費，包年僅需4折！

背景介紹

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）排查抖動源：

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

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常見問題之-fork操作]

杭州/西安/深圳簡歷投遞：yuwenlong4@huawei.com

GaussDB(for Redis)產品主頁：

https://www.huaweicloud.com/product/gaussdbforredis.html

更多技術文章，關注GaussDB(for Redis)官方博客：

https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813

Redis 云數據庫 GaussDB(for Redis) 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。