1.前言

Kafka 作為流處理平臺，在實時流計算和在線業(yè)務場景，追尾讀追求端到端低延遲。在離線批處理和削峰填谷場景，數(shù)據(jù)冷讀追求高吞吐。兩個場景都需要很好的數(shù)據(jù)緩存設計來支撐，Apache Kafka 的數(shù)據(jù)存儲在本地文件，通過 mmap 將文件映射到內(nèi)存中訪問，天然就可以依托操作系統(tǒng)來完成文件的緩沖持久化、緩存加載和緩存驅(qū)逐。

AutoMQ 采用存算分離的架構，將存儲分離至對象存儲，本地沒有數(shù)據(jù)文件，因此無法像 Apache Kafka 一樣直接使用數(shù)據(jù)文件 mmap 來進行數(shù)據(jù)緩存。這時候通常緩存對象存儲的數(shù)據(jù)有兩種做法：

• 第一種是將對象存儲文件下載到本地文件，然后再通過 mmap 讀取本地文件。這種做法在實現(xiàn)上比較簡單，但是需要一塊額外的磁盤來緩存數(shù)據(jù)，然后根據(jù)緩存所需的大小和速率，還需要購買磁盤空間和 IOPS，該做法不夠經(jīng)濟；
• 第二種是根據(jù)流處理的數(shù)據(jù)消費特征，直接基于內(nèi)存來進行數(shù)據(jù)緩存。這種做法實現(xiàn)起來會復雜一些，相當于需要實現(xiàn)一個類似操作系統(tǒng)的內(nèi)存管理。但是就像萬事萬物都有兩面性一樣，自己實現(xiàn)內(nèi)存緩存管理，就可以根據(jù)業(yè)務場景取得最佳的緩存效率和經(jīng)濟性。

為了降低運維的復雜性和持有成本，提高緩存的效率，AutoMQ 最終選擇的是第二種做法：“直接基于內(nèi)存來進行數(shù)據(jù)緩存”。

2.AutoMQ 緩存設計

直接基于內(nèi)存來進行數(shù)據(jù)緩存，AutoMQ 針對追尾讀和冷讀兩個場景，根據(jù)兩者的數(shù)據(jù)訪問特點，設計了兩套緩存機制：LogCache 和 BlockCache。

圖片

LogCache 針對于追尾讀場景設計，數(shù)據(jù)上傳到對象存儲的同時，也會以單個 RecordBatch 的形式在 LogCache 中緩存一份，這樣熱數(shù)據(jù)就可以從直接緩存中獲取，提供極低的端到端延遲。相比操作系統(tǒng)通用的緩存設計，LogCache 還具備以下兩個特質(zhì)：

• FIFO：針對追尾讀持續(xù)訪問新數(shù)據(jù)的特點，LogCache 采用先入先出的緩存驅(qū)逐策略，優(yōu)先保證新數(shù)據(jù)緩存的可用性；
• 低延遲：LogCache 有獨占的緩存空間，只負責熱數(shù)據(jù)的緩存，避免了冷數(shù)據(jù)讀取影響熱數(shù)據(jù)消費的問題。

BlockCache 針對冷讀場景設計，當無法在 LogCache 中訪問到需要的數(shù)據(jù)時，則從 BlockCache 中讀取。BlockCache 相比 LogCache 具備以下兩個不同點：

• LRU：BlockCache 使用 Least Recently Used 策略來進行緩存驅(qū)逐，在多倍 Fanout 的冷讀場景可以獲得更佳的緩存利用率；
• 高吞吐：冷讀關注的是吞吐量，因此 BlockCache 會大塊（～4MB）的從對象存儲讀取 & 緩存數(shù)據(jù)，并且通過預讀策略來提前加載后續(xù)可能讀取的數(shù)據(jù)；

Java 程序中在內(nèi)存中緩存數(shù)據(jù)可以選擇堆內(nèi)內(nèi)存或堆外內(nèi)存。為了減輕 JVM GC 的負擔，AutoMQ 使用堆外內(nèi)存 Direct Memory 來緩存數(shù)據(jù)，并且為了提高 Direct Memory 的申請效率，采用業(yè)界成熟的 Netty PooledByteBufAllocator 從池化內(nèi)存中進行內(nèi)存的申請和釋放。

3.“慘案”發(fā)生

期望是使用 Netty 的 PooledByteBufAllocator 后，AutoMQ 既可以通過池化來獲得高效的內(nèi)存分配速度，又有久經(jīng)打磨的內(nèi)存分配策略來最小化內(nèi)存分配的 Overhead，就可以高枕無憂無憂了，然而在 AutoMQ 1.0.0 RC 壓測過程中被現(xiàn)實給了當頭一棒。

AutoMQ 生產(chǎn)機型為 2C16G，設置堆外內(nèi)存使用上限 6GiB -XX:MaxDirectMemorySize=6G，內(nèi)存分配為 2GiB LogCache + 1GiB BlockCache + 1GiB 其他小項 ～= 4GiB < 6GiB。理論計算下，堆外內(nèi)存還綽綽有余，然而在實際 AutoMQ 1.0.0 RC 版在各種不同負載下長時間運行后發(fā)現(xiàn)，分配內(nèi)存有 OOM OutOfMemoryError 異常拋出。

本著優(yōu)先懷疑自己而不是懷疑成熟的類庫和操作系統(tǒng)的原則。

觀測到異常后，首先懷疑的是代碼中哪里有遺漏調(diào)用 ByteBuf#release。于是調(diào)整 Netty 的泄漏檢測等級 -Dio.netty.leakDetection.level=PARANOID，檢測每個的 ByteBuf 是否有存在被 GC 但是還沒有被釋放的問題。跑了一段時間未發(fā)現(xiàn)有 Leak 日志，于是乎排除漏釋放的可能。

接著懷疑點轉(zhuǎn)移到是否代碼中有哪塊內(nèi)存分配量超出了預期值。Netty 的 ByteBufAllocatorMetric只提供全局的內(nèi)存占用統(tǒng)計，傳統(tǒng)的內(nèi)存分配火焰圖也只能提供特定時間的內(nèi)存申請量，而我們需要的是某個時刻各種類型的內(nèi)存使用量。因此 AutoMQ 將 ByteBuf 的申請收口到自己實現(xiàn)的 ByteBufAlloc工廠類中，通過WrappedByteBuf 跟蹤各種類型內(nèi)存的申請和釋放，以此來記錄當前時刻各個類型的內(nèi)存使用量。并且將 Netty 的實際內(nèi)存使用量也記錄下來，這樣就知道 AutoMQ 總體內(nèi)存和分類內(nèi)存的使用量。

Buffer usage: 
ByteBufAllocMetric{allocatorMetric=PooledByteBufAllocatorMetric(usedDirectMemory: 2294284288; ...), // Physical Memory Size Allocated by Netty
allocatedMemory=1870424720, // Total Memory Size Requested By AutoMQ
1/write_record=1841299456, 11/block_cache=0, ..., // Detail Memory Size Requested By AutoMQ
pooled=true, direct=true} (com.automq.stream.s3.ByteBufAlloc)

加上分類內(nèi)存統(tǒng)計后，發(fā)現(xiàn)各種類型的內(nèi)存使用量都在預期范圍內(nèi)。不過異常的是，AutoMQ 申請的內(nèi)存量和 Netty 實際申請的內(nèi)存量有較大的差距，并且隨著運行兩者之間的差值越來越大，甚至有時候 Netty 實際升級的內(nèi)存是 AutoMQ 申請的內(nèi)存量的兩倍，這個差值為內(nèi)存分配的內(nèi)存碎片。

最終 OOM 的誘發(fā)原因定位為 Netty PooledByteBufAllocator 的內(nèi)存碎片。初步定位了問題的原因，那么問題轉(zhuǎn)換為 Netty 為什么會有內(nèi)存碎片和 AutoMQ 如何規(guī)避內(nèi)存碎片問題。

4.Netty 內(nèi)存碎片

首先我們來探索一下 Netty 內(nèi)存碎片的原因。Netty 的內(nèi)存碎片分為內(nèi)部碎片和外部碎片：

• 內(nèi)部碎片：由于 size 規(guī)約化對齊引起的碎片，例如期望分配 1byte，但是底層實際占用了 16byte，那么內(nèi)部碎片就浪費了 15byte；
• 外部碎片：簡單的來說，所有除了內(nèi)部碎片以外引起的碎片都算外部碎片，通常是由于分配算法導致的內(nèi)存布局碎片導致的；

內(nèi)部碎片和外部碎片，在不同的 Netty 版本有不同的表現(xiàn)，下面將以 Netty 4.1.52 版本為分割線簡要介紹一下 Buddy 分配算法和 PageRun/PoolSubPage 分配算法的工作機制和內(nèi)存碎片成因。

4.1 Buddy 分配算法 Netty < 4.1.52

Netty < 4.1.52 采用 Buddy 分配算法，算法源自 jemalloc3。Netty 為了提升內(nèi)存申請的效率，會一次性從操作系統(tǒng)申請一段連續(xù)內(nèi)存（PoolChunk），在上層申請 ByteBuf 時，按需將這一段內(nèi)存邏輯拆分返回給上層。默認 PoolChunk 的大小為 16MB，PoolChunk 邏輯上被劃分為 2048 個 8KB 大小的 Page，通過一個完全二叉樹來表示內(nèi)存的使用情況。

圖片

完全二叉樹的每個節(jié)點用一個 byte 來表示節(jié)點的狀態(tài)（memoryMap）：

• 初始值為層數(shù)，狀態(tài)值 == 層數(shù)代表該節(jié)點完全空閑；
• 當層數(shù) < 狀態(tài)值 < 12 時，代表該節(jié)點被使用了一部分，但仍舊有剩余空間；
• 當狀態(tài)值 == 12 時，代表該節(jié)點已經(jīng)被完全分配；

內(nèi)存分配分為 Tiny [0， 512byte] 、 Small （512byte， 8KB） 、 Normal [8KB， 16M] 和 Huge （16M， Max） 四種類型，其中 Tiny 和 Small 由 PoolSubpage 負責，Normal 由 PoolChunk 負責，Huge 直接分配。

先來看看小內(nèi)存塊的分配效率，Tiny [0， 512byte] 和 Small （512byte， 8KB） 將一個 Page 通過 PoolSubpage 切分成等長的邏輯塊，由一個 bitmap 來標記塊的使用情況：

• Tiny 內(nèi)存分配的基礎單位為 16 byte，意味著如果請求大小為 50 byte，實際分配的是 64 byte，內(nèi)部碎片率為 28%；
• Small 內(nèi)存分配的基礎單位是 1KB，意味著請求大小為 1.5KB，實際分配的是 2KB，內(nèi)部碎片率為 25%；

再來看看中等的內(nèi)存塊 Normal [8KB， 16M]，假設從一個完全空閑的 PoolChunk 申請 2MB + 1KB = 2049KB 內(nèi)存：

• 2049KB 以 2 為底向上規(guī)格化后變?yōu)?4MB，于是查找目標為 Depth-3 的空閑節(jié)點；
• 檢查 index=1 節(jié)點，發(fā)現(xiàn)節(jié)點有空閑，則檢查左子樹；
• 檢查 index=2 節(jié)點，發(fā)現(xiàn)節(jié)點有空閑，則繼續(xù)檢查左子樹；
• 檢查 index=4 節(jié)點，發(fā)現(xiàn)節(jié)點未被分配，則將 index=4 的狀態(tài)標記為 12，并且將父節(jié)點的狀態(tài)更新為兩個子節(jié)點中最小的那個，也就是將 index=2 的狀態(tài)變?yōu)?3，同理依次更新父節(jié)點狀態(tài)；
• 分配完成；

從分配結果可以看出，申請 2049KB 內(nèi)存，實際標記占用 4MB 內(nèi)存，意味著內(nèi)部碎片率為 49.9%。

假設再申請一個 9MB 的內(nèi)存，雖然剛才的 PoolChunk 仍有 12MB 的剩余空間，但是由于 Buddy 內(nèi)存分配算法的原理，index=1 已經(jīng)被占用了部分，此時只能新開一個 PoolChunk 來分配 9MB 的內(nèi)存。分配后的外部碎片率為 1 - （4MB + 9MB） / 32MB = 59.3%。最終所需內(nèi)存 / 底層實際占用內(nèi)存 = 有效內(nèi)存利用率 = 僅為 34.3%。

更進一步，在各種不同大小的內(nèi)存塊持續(xù)的分配釋放場景，即使 PoolChunk 實際分配出去的空間不大，也有可能被零散的內(nèi)存塊邏輯分割，進一步增加更多的外部內(nèi)存碎片。以下圖為例，雖然上層應用最終只保留了 4 * 8KB，但是已經(jīng)無法再從這個 PoolChunk 申請 4MB 的內(nèi)存了。

圖片

4.2 PageRun/PoolSubpage 分配算法 Netty >= 4.1.52

Netty >= 4.1.52 參考 jemalloc4 將內(nèi)存分配升級到 PageRun/PoolSubPage 分配策略。相比原來的 Buddy 分配算法無論在小內(nèi)存的分配還是在大內(nèi)存的分配都有低的內(nèi)部 & 外部內(nèi)存碎片率。

PageRun/PoolSubpage 分配算法相比原來 Buddy 分配算法：

• Chunk 默認大小從 16MB 變?yōu)?4MB；
• 保留了 Chunk 和 Page，增加了 Run 的概念，一串連續(xù)的 Pages 組成一個 Run，通過 Run 來分配 Normal （28KB， 4MB）  中等內(nèi)存；
• 將 Tiny 和 Small 級別的內(nèi)存塊替換成可跨多個 Page & [16byte ... 28KB] 共 38 級基礎分配大小的 PoolSubpage；

圖片

首先仍舊是先看看小內(nèi)存塊的分配效率，以申請 1025 byte 為例：

•  首先 1025 會根據(jù) PoolSubpage 級別規(guī)約到 1280 這個基礎分配大??；

sizeIdx2sizeTab=[16, 32, 48, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320, 384, 448, 512, 640, 768, 896, 1024, 1280, 1536, 1792, 2048, 2560, 3072, 3584, 4096, 5120, 6144, 7168, 8192, 10240, 12288, 14336, 16384, 20480, 24576, 28672, ...]

• 然后 PoolChunk 會對 1280 byte 和 Page Size 8K 取最小公倍數(shù) 40KB 來決定該 PoolSubPage 包含  5 個 Pages；
• 從 PoolChunk 中分配 5 個連續(xù)的 Pages，并通過 bitmapIdx 記錄已分配出去的 element；
• 至此分配完成，內(nèi)部碎片率為 1 -  1025 / 1280 = 19.9%

得益于 PoolSubpage 相比原來分級更加精細，從原來的 2 級變成 38 級，小內(nèi)存塊的分配效率大大提高。

然后再來看看中等的內(nèi)存塊 Normal （28KB， 4M] 的內(nèi)存分配效率。假設從一個完全空閑的 PoolChunk 申請 2MB + 1KB = 2049KB 內(nèi)存：

• 2049KB 按照 8KB 向上規(guī)整后，發(fā)現(xiàn)需要 257 個 Pages；
• PoolChunk 中找到滿足大小的 Run Run{offset=0, size=512}；
• PoolChunk 將 Run 拆分成 Run{offset=0, size=257} 和 Run{offset=257, size=255}，第一個 Run 返回給請求方，第二個 Run 加入到空閑 Run 列表（runsAvail）中；
• 至此分配完成，內(nèi)部碎片率為 1 - 2049KB / （257 * 8K） = 0.3%；

通過 PageRun 機制，Netty 可以控制大于 28KB 的內(nèi)存塊分配的內(nèi)存浪費不超過 8KB，內(nèi)部碎片率小于 22.2%。

假設再申請一個 1MB 的內(nèi)存，這時候 PoolChunk 仍舊運行相同的邏輯將 Run{offset=257, size=255} 拆分成 Run{offset=257, size=128} 和 Run{offset=385, size=127}，前者返回給上層，后者加入到空閑 Run 列表。此時外部碎片率為 25%。如果按照老的 Buddy 算法，在 PoolChunk 的大小為 4MB 的場景下，就需要新開一個 PoolChunk 了，外部碎片率為 62.5%。

雖然 PageRun/PoolSubpage 分配算法在大小內(nèi)存上相比原有的 Buddy 分配算法有更低的內(nèi)部內(nèi)存碎片率和外部內(nèi)存碎片率，但是畢竟不像 JVM 內(nèi)通過 GC 來 Compact 零散的內(nèi)存，仍舊會出現(xiàn)在各種不同大小的內(nèi)存塊持續(xù)的分配釋放場景，將 PoolChunk 中的可用 Run 切分很零碎，內(nèi)存碎片率逐漸提升最終導致 OOM。

5.AutoMQ 應對之道

前面介紹完 Netty 內(nèi)存分配的機制和內(nèi)存碎片產(chǎn)生的場景，那 AutoMQ 能怎么解決內(nèi)存碎片問題的呢？

LogCache 針對追尾讀持續(xù)訪問新數(shù)據(jù)的特點，采用先入先出的緩存驅(qū)逐策略，換個角度思考就是在相鄰時間分配內(nèi)存的會在相鄰時間釋放。AutoMQ 采用的策略是抽象一個 ByteBufSeqAlloc：

• ByteBufSeqAlloc 每次向 Netty 申請 ChunkSize 大小的 ByteBuf，避免產(chǎn)生外部內(nèi)存碎片，做到零外部內(nèi)存碎片；
• ByteBufSeqAlloc分配內(nèi)存時，通過底層 ByteBuf#retainSlice 緊挨著連續(xù)從底層大的內(nèi)存拆分出小的內(nèi)存，避免 size 規(guī)約化產(chǎn)生內(nèi)部內(nèi)存碎片，做到零內(nèi)部內(nèi)存碎片；
• 釋放的時候是相鄰的一起釋放，有可能一塊里面大部分都釋放了，但其中少部分還在有效期內(nèi)，這時候整個大塊都無法釋放，但這個大塊的浪費有且僅會存在一個，并且也只會浪費一個 ChunkSize 的大??；

BlockCache 的特點是追求冷讀高吞吐，會從對象存儲中大塊讀取數(shù)據(jù)段。AutoMQ 采用的策略是大塊緩存對象存儲中的原始數(shù)據(jù)：

• 按需解碼：等需要查詢時，再解碼成具體的 RecordBatch，通過降低常駐內(nèi)存塊的數(shù)量來降低內(nèi)存碎片；
• 規(guī)整化拆分：未來可以將大塊緩存規(guī)整化拆分成規(guī)整的 1MB 內(nèi)存塊，來避免各種不同大小的內(nèi)存塊持續(xù)的分配釋放導致的內(nèi)存碎片率逐漸提升；

圖片

可以看到 LogCache 和 BlockCache 優(yōu)化的本質(zhì)都是根據(jù)自身緩存的特點通過大塊 & 規(guī)整的內(nèi)存分配來規(guī)避 Netty 內(nèi)存分配策略帶來的內(nèi)存碎片問題。通過該方式，AutoMQ 在追尾讀、冷讀和大小消息等各種場景長期運行，也能將堆外內(nèi)存的內(nèi)存碎片率控制在 35% 以下，再也沒有出現(xiàn)過堆外內(nèi)存 OOM。

圖片

6.總結

Netty 的 PooledByteBufAllocator 不是銀彈，使用的時候需要考慮內(nèi)存碎片帶來的實際內(nèi)存占用的空間放大，規(guī)劃預留出合理的 JVM 內(nèi)存大小。如果只是使用 Netty 作為網(wǎng)絡層框架，由 PooledByteBufAllocator 分配的內(nèi)存生命周期會比較短，因此內(nèi)存碎片引起的內(nèi)存放大實際并不會很明顯，不過仍舊建議使用 Netty 的系統(tǒng)都將版本升級到 4.1.52 之上，以獲得更好的內(nèi)存分配效率。如果使用 Netty 的 PooledByteBufAllocator 來做緩存，建議根據(jù)緩存的特征，使用大塊內(nèi)存分配然后再自行連續(xù)拆分，來規(guī)避 Netty 的內(nèi)存碎片。

參考文檔

1. https://netty.io/wiki/reference-counted-objects.html
2. https://netty.io/news/2020/09/08/4-1-52-Final.html