RocketMQ on openEuler，是一種將 RocketMQ 消息中間件通過容器化的方式部署在 openEuler 操作系統上運行，借助 openEuler 系統對于 OS 緩存回收效率增強的內核特性，提升消息中間件在面向超大規模高并發、高吞吐量、低延遲場景下穩定性和可靠性的軟件解決方案。

RocketMQ 消息隊列在穩壓測試中遇到的 OOM 問題

移動云 RocketMQ 消息隊列產品正式上線前，通過壓測工具，創建多組生產者/消費者進程對 RocketMQ 獨享集群做多輪性能和穩定性的壓力測試。

測試環境

壓測結果

在某次持續長時間的壓測過程中，發現消息收發吞吐，在一段時間內的某一時刻會出現大幅度 TPS（生產/消費）抖動下降的現象，并且是周期性的。

移動云 RocketMQ 消息隊列一直都比較穩定運行，為何在高并發的壓測下也會出現 TPS 的抖動？我們初步懷疑是 CPU 負載或者 RocketMQ Broker 組件 GC 頻率過高導致，但通過查看 CPU 負載和 JVM GC 頻率并未發現任何異常。最終，經過排查發現是由于 Broker Pod 進程中的 buff/cache 在持續長時間壓測下不斷增加，系統無法及時有效回收，導致 Pod 中的運行進程占用內存空間超出預先設置的 Limit 限制，觸發了 OOM Killer 機制重啟了 Broker Pod。

RocketMQ on openEuler—解決大規模高并發場景下提升穩定性的新選擇

為何在持續高并發下進行消息收發會導致系統的 buff/cache 的持續增加？通過翻閱操作系統手冊，可知 buff/cache 主要體現在系統的 PageCache 上。

PageCache 在 RocketMQ 消息存儲中的重要作用

PageCache 也叫頁緩沖或文件緩沖，在 linux 讀寫文件時，它用于緩存文件的邏輯內容，從而加快對磁盤上映像和數據的訪問。

上圖中，紅色部分即為，PageCache。可見 PageCache 的本質是由 Linux 內核管理的內存區域。平時我們寫的各種程序，通過 mmap 及 buffered I/O 將文件讀取到內存空間實際上都是讀取到 PageCache 中。為了在大規模高并發場景下實現實現低延遲、高吞吐的目標，RocketMQ 消息隊列的存儲模塊主要采用如下兩種方案。

「Mmap + PageCache 的消息并發讀寫方案」：在該方案中，消息的讀寫流程都會經過 PageCache。在多線程并發讀寫的場景下，PageCache 不可避免會有鎖的問題，尤其是在維護 PageCache 一致性時，系統回刷臟頁時磁盤壓力較高，會導致出現毛刺現象。

「堆外內存池化技術 + PageCache 的消息讀寫分離方案」：消息寫入時候寫至 RocketMQ 啟動時創建的堆外內存塊（DirectByteBuffer）中，同時消息從 PageCache 中讀取。這樣，消息讀寫分離使得整體流程并發性更好，有效降低時延，同時利用堆外內存池減少了用戶態與內核態的切換開銷。

PageCache 在 RocketMQ 消息隊列的存儲層扮演著舉足輕重的作用，一旦系統的 PageCache 出現問題（如緩存回收、一致性和缺頁中斷等問題），都會對消息收發的主要流程造成嚴重的影響。

openEuler 系統在緩存回收效率方面的優化

為了防止 PageCache 申請過多（默認無限制）將可靠內存耗盡，需要對 PageCache 的總量及使用可靠內存總量進行限制。相對于 CentOS 系統內核無法對未超出 node 節點內存資源的 PageCache 進行及時回收，openEuler 針對 PageCache 的回收增加了相關的系統內核參數，并為限制 PageCache 使用量的功能提供若干 proc 接口，接口定義在/proc/sys/vm/下，用來控制 PageCache 的使用量，具體如下：

「cache_reclaim_enable」：表示 PageCache 限制的功能的使能開關；

「cache_reclaim_s」：表示定期觸發 cache 回收的時間，以秒為單位。系統會根據當前 online 的 cpu 個數來創建工作隊列，如果有 n 個 cpu 則創建 n 個工作隊列，每個工作隊列每隔 cache_reclaim_s 秒進行一次回收。該參數與 cpu 上下線功能兼容，如果 cpu offline，則會減少工作隊列個數；反之，cpu online 則會增加工作隊列個數。

「cache_reclaim_weight」：表示每次回收的權值，內核每個 CPU 每次期望回收 32 * cache_reclaim_weight 個 page。該權值同時作用于 page 上限觸發的回收和定期 pageCache 回收；

RocketMQ on openEuler 方案在生產環境中的驗證

為解決遇到的 OOM 問題，我們針對獨享集群所在機器進行了操作系統內核版本的升級，更新至最新的 BC-Linux for Euler 21.10 版本（BC-Linux for Euler 是移動云操作系統團隊以 openEuler 社區操作系統為基礎，借助開源社區的開放優勢，通過定制化方式研發的企業級 Linux 操作系統）。更新系統后，采用兩種消息體（1Kb 和 4Kb）分別對同樣的測試環境進行長時間的壓測。

測試場景 1

測試消息大小 1Kb 消息收發性能及長時間壓測穩定性，測試中，獨享集群能夠達到收發消息總和 TPS 為 2w+TPS（其中發送消息 1w+TPS，消費消息 1w+TPS）。消息生產和消費的速度規律，如下圖所示：

從圖中可見在消息體大小為 1Kb 的消息時，消息生產和消費速度在長時間壓測下沒有抖動，TPS 保持平穩，整個壓測時間服務正常。

測試場景 2

測試消息大小 4Kb 消息收發性能及長時間壓測穩定性，測試中，集群能夠達到收發消息總和 TPS 為 1.4w+ TPS（其中發送消息 0.7w+TPS，消費消息 0.7w+TPS）。消息生產和消費的速度規律，如下圖所示：

從圖中可見在消息體大小為 4Kb 的消息時，消息生產和消費速度長時間壓測沒有抖動，TPS 保持平穩，整個壓測時間服務正常。

總結

移動云 RocketMQ 消息隊列的獨享實例在 22 年已完成了云原生化的完全升級，特別適合云原生、Serverless 化架構和大數據流計算的技術演進與相關應用場景。目前，RocketMQ on openEuler 的解決方案已在廣州 3 AZ2、呼和浩特、北京、杭州等多個資源池上線且完成了部分存量服務器的遷移與改造升級。后續，移動云 RocketMQ 消息隊列并將不斷提升服務質量，為廣大客戶創造更多的價值。歡迎大家多多關注。

審核編輯：湯梓紅