vivo TWS Air開箱體驗：真輕 臻好聽
在vivo S15系列新機的發布會上，vivo的最新款真無線藍牙耳機vivo TWS Air也一同發布，本次就這款耳機新品給大家帶來一個簡單的分享。外包裝盒上，vivo TWS Air保持了vivo自家產
Kafka 作為流處理平臺，在實時流計算和在線業務場景，追尾讀追求端到端低延遲。在離線批處理和削峰填谷場景，數據冷讀追求高吞吐。兩個場景都需要很好的數據緩存設計來支撐，Apache Kafka 的數據存儲在本地文件，通過 mmap 將文件映射到內存中訪問，天然就可以依托操作系統來完成文件的緩沖持久化、緩存加載和緩存驅逐。
AutoMQ 采用存算分離的架構，將存儲分離至對象存儲，本地沒有數據文件，因此無法像 Apache Kafka 一樣直接使用數據文件 mmap 來進行數據緩存。這時候通常緩存對象存儲的數據有兩種做法：
為了降低運維的復雜性和持有成本，提高緩存的效率，AutoMQ 最終選擇的是第二種做法：“直接基于內存來進行數據緩存”。
直接基于內存來進行數據緩存，AutoMQ 針對追尾讀和冷讀兩個場景，根據兩者的數據訪問特點，設計了兩套緩存機制：LogCache 和 BlockCache。
圖片
LogCache 針對于追尾讀場景設計，數據上傳到對象存儲的同時，也會以單個 RecordBatch 的形式在 LogCache 中緩存一份，這樣熱數據就可以從直接緩存中獲取，提供極低的端到端延遲。相比操作系統通用的緩存設計，LogCache 還具備以下兩個特質：
BlockCache 針對冷讀場景設計，當無法在 LogCache 中訪問到需要的數據時，則從 BlockCache 中讀取。BlockCache 相比 LogCache 具備以下兩個不同點：
Java 程序中在內存中緩存數據可以選擇堆內內存或堆外內存。為了減輕 JVM GC 的負擔，AutoMQ 使用堆外內存 Direct Memory 來緩存數據，并且為了提高 Direct Memory 的申請效率，采用業界成熟的 Netty PooledByteBufAllocator 從池化內存中進行內存的申請和釋放。
期望是使用 Netty 的 PooledByteBufAllocator 后，AutoMQ 既可以通過池化來獲得高效的內存分配速度，又有久經打磨的內存分配策略來最小化內存分配的 Overhead，就可以高枕無憂無憂了，然而在 AutoMQ 1.0.0 RC 壓測過程中被現實給了當頭一棒。
AutoMQ 生產機型為 2C16G，設置堆外內存使用上限 6GiB -XX:MaxDirectMemorySize=6G，內存分配為 2GiB LogCache + 1GiB BlockCache + 1GiB 其他小項 ～= 4GiB < 6GiB。理論計算下，堆外內存還綽綽有余，然而在實際 AutoMQ 1.0.0 RC 版在各種不同負載下長時間運行后發現，分配內存有 OOM OutOfMemoryError 異常拋出。
本著優先懷疑自己而不是懷疑成熟的類庫和操作系統的原則。
觀測到異常后，首先懷疑的是代碼中哪里有遺漏調用 ByteBuf#release。于是調整 Netty 的泄漏檢測等級 -Dio.netty.leakDetection.level=PARANOID，檢測每個的 ByteBuf 是否有存在被 GC 但是還沒有被釋放的問題。跑了一段時間未發現有 Leak 日志，于是乎排除漏釋放的可能。
接著懷疑點轉移到是否代碼中有哪塊內存分配量超出了預期值。Netty 的 ByteBufAllocatorMetric只提供全局的內存占用統計，傳統的內存分配火焰圖也只能提供特定時間的內存申請量，而我們需要的是某個時刻各種類型的內存使用量。因此 AutoMQ 將 ByteBuf 的申請收口到自己實現的 ByteBufAlloc工廠類中，通過WrappedByteBuf 跟蹤各種類型內存的申請和釋放，以此來記錄當前時刻各個類型的內存使用量。并且將 Netty 的實際內存使用量也記錄下來，這樣就知道 AutoMQ 總體內存和分類內存的使用量。
Buffer usage: ByteBufAllocMetric{allocatorMetric=PooledByteBufAllocatorMetric(usedDirectMemory: 2294284288; ...), // Physical Memory Size Allocated by NettyallocatedMemory=1870424720, // Total Memory Size Requested By AutoMQ1/write_record=1841299456, 11/block_cache=0, ..., // Detail Memory Size Requested By AutoMQpooled=true, direct=true} (com.automq.stream.s3.ByteBufAlloc)加上分類內存統計后，發現各種類型的內存使用量都在預期范圍內。不過異常的是，AutoMQ 申請的內存量和 Netty 實際申請的內存量有較大的差距，并且隨著運行兩者之間的差值越來越大，甚至有時候 Netty 實際升級的內存是 AutoMQ 申請的內存量的兩倍，這個差值為內存分配的內存碎片。
最終 OOM 的誘發原因定位為 Netty PooledByteBufAllocator 的內存碎片。初步定位了問題的原因，那么問題轉換為 Netty 為什么會有內存碎片和 AutoMQ 如何規避內存碎片問題。
首先我們來探索一下 Netty 內存碎片的原因。Netty 的內存碎片分為內部碎片和外部碎片：
內部碎片和外部碎片，在不同的 Netty 版本有不同的表現，下面將以 Netty 4.1.52 版本為分割線簡要介紹一下 Buddy 分配算法和 PageRun/PoolSubPage 分配算法的工作機制和內存碎片成因。
Netty < 4.1.52 采用 Buddy 分配算法，算法源自 jemalloc3。Netty 為了提升內存申請的效率，會一次性從操作系統申請一段連續內存（PoolChunk），在上層申請 ByteBuf 時，按需將這一段內存邏輯拆分返回給上層。默認 PoolChunk 的大小為 16MB，PoolChunk 邏輯上被劃分為 2048 個 8KB 大小的 Page，通過一個完全二叉樹來表示內存的使用情況。
圖片
完全二叉樹的每個節點用一個 byte 來表示節點的狀態（memoryMap）：
內存分配分為 Tiny [0， 512byte] 、 Small （512byte， 8KB） 、 Normal [8KB， 16M] 和 Huge （16M， Max） 四種類型，其中 Tiny 和 Small 由 PoolSubpage 負責，Normal 由 PoolChunk 負責，Huge 直接分配。
先來看看小內存塊的分配效率，Tiny [0， 512byte] 和 Small （512byte， 8KB） 將一個 Page 通過 PoolSubpage 切分成等長的邏輯塊，由一個 bitmap 來標記塊的使用情況：
再來看看中等的內存塊 Normal [8KB， 16M]，假設從一個完全空閑的 PoolChunk 申請 2MB + 1KB = 2049KB 內存：
從分配結果可以看出，申請 2049KB 內存，實際標記占用 4MB 內存，意味著內部碎片率為 49.9%。
假設再申請一個 9MB 的內存，雖然剛才的 PoolChunk 仍有 12MB 的剩余空間，但是由于 Buddy 內存分配算法的原理，index=1 已經被占用了部分，此時只能新開一個 PoolChunk 來分配 9MB 的內存。分配后的外部碎片率為 1 - （4MB + 9MB） / 32MB = 59.3%。最終所需內存 / 底層實際占用內存 = 有效內存利用率 = 僅為 34.3%。
更進一步，在各種不同大小的內存塊持續的分配釋放場景，即使 PoolChunk 實際分配出去的空間不大，也有可能被零散的內存塊邏輯分割，進一步增加更多的外部內存碎片。以下圖為例，雖然上層應用最終只保留了 4 * 8KB，但是已經無法再從這個 PoolChunk 申請 4MB 的內存了。
圖片
Netty >= 4.1.52 參考 jemalloc4 將內存分配升級到 PageRun/PoolSubPage 分配策略。相比原來的 Buddy 分配算法無論在小內存的分配還是在大內存的分配都有低的內部 & 外部內存碎片率。
PageRun/PoolSubpage 分配算法相比原來 Buddy 分配算法：
圖片
首先仍舊是先看看小內存塊的分配效率，以申請 1025 byte 為例：
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, ...]得益于 PoolSubpage 相比原來分級更加精細，從原來的 2 級變成 38 級，小內存塊的分配效率大大提高。
然后再來看看中等的內存塊 Normal （28KB， 4M] 的內存分配效率。假設從一個完全空閑的 PoolChunk 申請 2MB + 1KB = 2049KB 內存：
通過 PageRun 機制，Netty 可以控制大于 28KB 的內存塊分配的內存浪費不超過 8KB，內部碎片率小于 22.2%。
假設再申請一個 1MB 的內存，這時候 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 分配算法在大小內存上相比原有的 Buddy 分配算法有更低的內部內存碎片率和外部內存碎片率，但是畢竟不像 JVM 內通過 GC 來 Compact 零散的內存，仍舊會出現在各種不同大小的內存塊持續的分配釋放場景，將 PoolChunk 中的可用 Run 切分很零碎，內存碎片率逐漸提升最終導致 OOM。
前面介紹完 Netty 內存分配的機制和內存碎片產生的場景，那 AutoMQ 能怎么解決內存碎片問題的呢？
LogCache 針對追尾讀持續訪問新數據的特點，采用先入先出的緩存驅逐策略，換個角度思考就是在相鄰時間分配內存的會在相鄰時間釋放。AutoMQ 采用的策略是抽象一個 ByteBufSeqAlloc：
BlockCache 的特點是追求冷讀高吞吐，會從對象存儲中大塊讀取數據段。AutoMQ 采用的策略是大塊緩存對象存儲中的原始數據：
圖片
可以看到 LogCache 和 BlockCache 優化的本質都是根據自身緩存的特點通過大塊 & 規整的內存分配來規避 Netty 內存分配策略帶來的內存碎片問題。通過該方式，AutoMQ 在追尾讀、冷讀和大小消息等各種場景長期運行，也能將堆外內存的內存碎片率控制在 35% 以下，再也沒有出現過堆外內存 OOM。
圖片
Netty 的 PooledByteBufAllocator 不是銀彈，使用的時候需要考慮內存碎片帶來的實際內存占用的空間放大，規劃預留出合理的 JVM 內存大小。如果只是使用 Netty 作為網絡層框架，由 PooledByteBufAllocator 分配的內存生命周期會比較短，因此內存碎片引起的內存放大實際并不會很明顯，不過仍舊建議使用 Netty 的系統都將版本升級到 4.1.52 之上，以獲得更好的內存分配效率。如果使用 Netty 的 PooledByteBufAllocator 來做緩存，建議根據緩存的特征，使用大塊內存分配然后再自行連續拆分，來規避 Netty 的內存碎片。
本文鏈接：http://www.tebozhan.com/showinfo-26-101722-0.html基于Netty的自研流系統緩存實現挑戰：內存碎片與OOM困境
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 淺析Vite插件機制，你學會了嗎？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號