背景
直播平臺內存泄漏問題:
某直播平臺,一些網紅的直播間在業務高峯期,會有 10W+ 的粉絲接入,如果瞬間發生大量客戶端連接掉線、或者一些客戶端網絡比較慢,發現基於 Netty
構建的服務端內存會飆升,發生內存泄漏(OOM),導致直播卡頓、或者客戶端接收不到服務端推送的消息,用戶體驗受到很大影響。
問題分析
首先對 GC 數據進行分析,發現老年代已滿,發生多次 Full GC,耗時達 3 分多,系統已經無法正常運行(示例):
Dump 內存堆棧進行分析,發現大量的發送任務堆積,導致內存溢出(示例):
通過以上分析可以看出,在直播高峯期,服務端向上萬客戶端推送消息時,發生了發送隊列積壓,引起內存泄漏,最終導致服務端頻繁 GC,無法正常處理業務。
解決策略
服務端在進行消息發送的時候做保護,具體策略如下:
- 根據可接入的最大用戶數做客戶端併發接入數流控,需要根據內存、CPU 處理能力,以及性能測試結果做綜合評估。
- 設置消息發送的高低水位,針對消息的平均大小、客戶端併發接入數、JVM 內存大小進行計算,得出一個合理的高水位取值。服務端在推送消息時,對 Channel 的狀態進行判斷,如果達到高水位之後,Channel 的狀態會被 Netty 置爲不可寫,此時服務端不要繼續發送消息,防止發送隊列積壓。
服務端基於上述策略優化了代碼,內存泄漏問題得到解決。
總結
儘管 Netty 框架本身做了大量的可靠性設計,但是對於具體的業務場景,仍然需要用戶做針對特定領域和場景的可靠性設計,這樣才能提升應用的可靠性。
除了消息發送積壓導致的內存泄漏,Netty 還有其它常見的一些內存泄漏點,本文將針對這些可能導致內存泄漏的功能點進行分析和總結。
消息收發防內存泄漏策略
消息收發防內存泄漏策略
Netty 的消息讀取並不存在消息隊列,但是如果消息解碼策略不當,則可能會發生內存泄漏,主要有如下幾點:
- 畸形碼流攻擊:如果客戶端按照協議規範,將消息長度值故意僞造的非常大,可能會導致接收方內存溢出。
- 代碼 BUG:錯誤的將消息長度字段設置或者編碼成一個非常大的值,可能會導致對方內存溢出。
- 高併發場景:單個消息長度比較大,例如幾十 M 的小視頻,同時併發接入的客戶端過多,會導致所有 Channel 持有的消息接收 ByteBuf 內存總和達到上限,發生 OOM。
避免內存泄漏的策略如下:
無論採用哪種解碼器實現,都對消息的最大長度做限制,當超過限制之後,拋出解碼失敗異常,用戶可以選擇忽略當前已經讀取的消息,或者直接關閉鏈接。
以 Netty 的 DelimiterBasedFrameDecoder 代碼爲例,創建 DelimiterBasedFrameDecoder
對象實例時,指定一個比較合理的消息最大長度限制,防止內存溢出:
/**
* Creates a new instance.
*
* @param maxFrameLength the maximum length of the decoded frame.
* A {@link TooLongFrameException} is thrown if
* the length of the frame exceeds this value.
* @param stripDelimiter whether the decoded frame should strip out the
* delimiter or not
* @param delimiter the delimiter
*/
public DelimiterBasedFrameDecoder(
int maxFrameLength, boolean stripDelimiter, ByteBuf delimiter) {
this(maxFrameLength, stripDelimiter, true, delimiter);
}
需要根據單個 Netty 服務端可以支持的最大客戶端併發連接數、消息的最大長度限制以及當前 JVM 配置的最大內存進行計算,並結合業務場景,合理設置maxFrameLength 的取值。
ChannelHandler 的併發執行
Netty 的 ChannelHandler 支持串行和異步併發執行兩種策略,在將 ChannelHandler 加入到 ChannelPipeline時,如果指定了 EventExecutorGroup,則 ChannelHandler 將由EventExecutorGroup 中的EventExecutor 異步執行。這樣的好處是可以實現 Netty I/O 線程與業務 ChannelHandler 邏輯執行的分離,防止ChannelHandler 中耗時業務邏輯的執行阻塞 I/O 線程。
如果業務 ChannelHandler 中執行的業務邏輯耗時較長,消息的讀取速度又比較快,很容易發生消息在 EventExecutor中積壓的問題,如果創建 EventExecutor 時沒有通過 io.netty.eventexecutor.maxPendingTasks參數指定積壓的最大消息個數,則默認取值爲 0x7fffffff,長時間的積壓將導致內存溢出,相關代碼如下所示(異步執行ChannelHandler,將消息封裝成 Task 加入到 taskQueue 中):
public void execute(Runnable task) {
if (task == null) {
throw new NullPointerException("task");
}
boolean inEventLoop = inEventLoop();
if (inEventLoop) {
addTask(task);
} else {
startThread();
addTask(task);
if (isShutdown() && removeTask(task)) {
reject();
}
}
**解決對策:**對 EventExecutor 中任務隊列的容量做限制,可以通io.netty.eventexecutor.maxPendingTasks參數做全局設置,也可以通過構造方法傳參設置。結合 EventExecutorGroup 中 EventExecutor 的個數來計算 taskQueue的個數,根據 taskQueue * N * 任務隊列平均大小 * maxPendingTasks < 係數 K (0 < K < 1)*總內存的公式來進行計算和評估。
消息發送
如何防止發送隊列積壓
爲了防止高併發場景下,由於對方處理慢導致自身消息積壓,除了服務端做流控之外,客戶端也需要做併發保護,防止自身發生消息積壓。
利用 Netty 提供的高低水位機制,可以實現客戶端更精準的流控。
當發送隊列待發送的字節數組達到高水位上限時,對應的 Channel 就變爲不可寫狀態。由於高水位並不影響業務線程調用 write方法並把消息加入到待發送隊列中,因此,必須要在消息發送時對 Channel 的狀態進行判斷:當到達高水位時,Channel 的狀態被設置爲不可寫,通過對
Channel 的可寫狀態進行判斷來決定是否發送消息。
在消息發送時設置高低水位並對 Channel 狀態進行判斷,相關代碼示例如下:
public void channelActive(final ChannelHandlerContext ctx) {
**ctx.channel().config().setWriteBufferHighWaterMark(10 \* 1024 * 1024);**
loadRunner = new Runnable() {
@Override
public void run() {
try {
TimeUnit.SECONDS.sleep(30);
} catch (InterruptedException e) {
e.printStackTrace();
}
ByteBuf msg = null;
while (true) {
**if (ctx.channel().isWritable()) {**
msg = Unpooled.wrappedBuffer("Netty OOM Example".getBytes());
ctx.writeAndFlush(msg);
} else {
LOG.warning("The write queue is busy : " + ctx.channel().unsafe().outboundBuffer().nioBufferSize());
}
}
}
};
new Thread(loadRunner, "LoadRunner-Thread").start();
}
對上述代碼做驗證,客戶端代碼中打印隊列積壓相關日誌,說明基於高水位的流控機制生效,日誌如下:
警告 : The write queue is busy : 17
通過內存監控,發現內存佔用平穩:
在實際項目中,根據業務 QPS
規劃、客戶端處理性能、網絡帶寬、鏈路數、消息平均碼流大小等綜合因素計算並設置高水位(WriteBufferHighWaterMark)閾值,利用高水位做消息發送速率的流控,既可以保護自身,同時又能減輕服務端的壓力,防止服務端被壓掛。
其它可能導致發送隊列積壓的因素
需要指出的是,並非只有高併發場景纔會觸發消息積壓,在一些異常場景下,儘管系統流量不大,但仍然可能會導致消息積壓,可能的場景包括:
- 網絡瓶頸,發送速率超過網絡鏈接處理能力時,會導致發送隊列積壓。
- 對端讀取速度小於己方發送速度,導致自身 TCP 發送緩衝區滿,頻繁發生 write 0 字節時,待發送消息會在 Netty 發送隊列排隊。
當出現大量排隊時,很容易導致 Netty 的直接內存泄漏,示例如下:
我們在設計系統時,需要根據業務的場景、所處的網絡環境等因素進行綜合設計,爲潛在的各種故障做容錯和保護,防止因爲外部因素導致自身發生內存泄漏。
ByteBuf 的申請和釋放策略
ByteBuf 申請和釋放的理解誤區
有一種說法認爲 Netty 框架分配的 ByteBuf 框架會自動釋放,業務不需要釋放;業務創建的 ByteBuf 則需要自己釋放,Netty框架不會釋放。
事實上,這種觀點是錯誤的,即便 ByteBuf 是 Netty 創建的,如果使用不當仍然會發生內存泄漏。在實際項目中如何更好的管理ByteBuf,下面我們分四種場景進行說明。
1、基於內存池的請求 ByteBuf
這類 ByteBuf 主要包括 PooledDirectByteBuf 和 PooledHeapByteBuf,它由 Netty 的
NioEventLoop 線程在處理 Channel 的讀操作時分配,需要在業務 ChannelInboundHandler
處理完請求消息之後釋放(通常是解碼之後),它的釋放有 2 種策略:
- 策略 1:業務 ChannelInboundHandler 繼承自 SimpleChannelInboundHandler,實現它的抽象方法 channelRead0(ChannelHandlerContext ctx, I msg),ByteBuf 的釋放業務不用關心,由 SimpleChannelInboundHandler 負責釋放,相關代碼如下所示(SimpleChannelInboundHandler):
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
boolean release = true;
try {
if (acceptInboundMessage(msg)) {
I imsg = (I) msg;
channelRead0(ctx, imsg);
} else {
release = false;
ctx.fireChannelRead(msg);
}
} finally {
if (autoRelease && release) {
ReferenceCountUtil.release(msg);
}
}
}
如果當前業務 ChannelInboundHandler 需要執行,則調用完 channelRead0 之後執行
ReferenceCountUtil.release(msg) 釋放當前請求消息。如果沒有匹配上需要繼續執行後續的
ChannelInboundHandler,則不釋放當前請求消息,調用 ctx.fireChannelRead(msg) 驅動
ChannelPipeline 繼續執行。
繼承自 SimpleChannelInboundHandler,即便業務不釋放請求 ByteBuf 對象,依然不會發生內存泄漏,相關示例代碼如下所示:
public class RouterServerHandlerV2**extends SimpleChannelInboundHandler<ByteBuf>**{
// 代碼省略 ...
@Override
public void channelRead0(ChannelHandlerContext ctx, ByteBuf msg) {
byte [] body = new byte[msg.readableBytes()];
executorService.execute(()->
{
// 解析請求消息,做路由轉發,代碼省略 ...
// 轉發成功,返回響應給客戶端
ByteBuf respMsg = allocator.heapBuffer(body.length);
respMsg.writeBytes(body);// 作爲示例,簡化處理,將請求返回
ctx.writeAndFlush(respMsg);
});
}
對上述代碼做性能測試,發現內存佔用平穩,無內存泄漏問題,驗證了之前的分析結論。
- 策略 2:在業務 ChannelInboundHandler 中調用 ctx.fireChannelRead(msg) 方法,讓請求消息繼續向後執行,直到調用到 DefaultChannelPipeline 的內部類 TailContext,由它來負責釋放請求消息,代碼如下所示(TailContext):
protected void onUnhandledInboundMessage(Object msg) {
try {
logger.debug(
"Discarded inbound message {} that reached at the tail of the pipeline. " +
"Please check your pipeline configuration.", msg);
} finally {
ReferenceCountUtil.release(msg);
}
}
2、基於非內存池的請求 ByteBuf
如果業務使用非內存池模式覆蓋 Netty 默認的內存池模式創建請求 ByteBuf,例如通過如下代碼修改內存申請策略爲 Unpooled:
.childHandler(new ChannelInitializer() {
@Override
public void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline p = ch.pipeline();
ch.config().setAllocator(UnpooledByteBufAllocator.DEFAULT);
p.addLast(new RouterServerHandler());
}
});
}
也需要按照內存池的方式去釋放內存。
3、基於內存池的響應 ByteBuf
只要調用了 writeAndFlush 或者 flush 方法,在消息發送完成之後都會由 Netty 框架進行內存釋放,業務不需要主動釋放內存。
它的工作原理如下:
調用 ctx.writeAndFlush(respMsg) 方法,當消息發送完成之後,Netty 框架會主動幫助應用來釋放內存,內存的釋放分爲兩種場景:
- 如果是堆內存(PooledHeapByteBuf),則將 HeapByteBuffer 轉換成 DirectByteBuffer,並釋放 PooledHeapByteBuf 到內存池,代碼如下(AbstractNioChannel 類):
protected final ByteBuf newDirectBuffer(ByteBuf buf) {
final int readableBytes = buf.readableBytes();
if (readableBytes == 0) {
**ReferenceCountUtil.safeRelease(buf);**
return Unpooled.EMPTY_BUFFER;
}
final ByteBufAllocator alloc = alloc();
if (alloc.isDirectBufferPooled()) {
ByteBuf directBuf = alloc.directBuffer(readableBytes);
directBuf.writeBytes(buf, buf.readerIndex(), readableBytes);
**ReferenceCountUtil.safeRelease(buf);**
return directBuf;
} }
// 後續代碼省略
}
- 如果消息完整的被寫到 SocketChannel 中,則釋放 DirectByteBuffer,代碼如下(ChannelOutboundBuffer)所示:
public boolean remove() {
Entry e = flushedEntry;
if (e == null) {
clearNioBuffers();
return false;
}
Object msg = e.msg;
ChannelPromise promise = e.promise;
int size = e.pendingSize;
removeEntry(e);
if (!e.cancelled) {
**ReferenceCountUtil.safeRelease(msg);**
safeSuccess(promise);
decrementPendingOutboundBytes(size, false, true);
}
// 後續代碼省略
}
對 Netty 源碼進行斷點調試,驗證上述分析:
- 斷點 1:在響應消息發送處打印斷點,獲取到 PooledUnsafeHeapByteBuf 實例 ID 爲 1506。
- 斷點 2:在 HeapByteBuffer 轉換成 DirectByteBuffer 處打斷點,發現實例 ID 爲 1506 的
PooledUnsafeHeapByteBuf 被釋放。
- 斷點 3:轉換之後待發送的響應消息 PooledUnsafeDirectByteBuf 實例 ID 爲 1527
- 斷點 4:響應消息發送完成之後,實例 ID 爲 1527 的 PooledUnsafeDirectByteBuf 被釋放到內存池。
如果是 DirectByteBuffer,則不需要轉換,當消息發送完成之後,由 ChannelOutboundBuffer 的 remove() 負責釋放。
4、基於非內存池的響應 ByteBuf
無論是基於內存池還是非內存池分配的 ByteBuf,如果是堆內存,則將堆內存轉換成堆外內存,然後釋放HeapByteBuffer,待消息發送完成之後,再釋放轉換後的 DirectByteBuf;如果是
DirectByteBuffer,則無需轉換,待消息發送完成之後釋放。因此對於需要發送的響應 ByteBuf,由業務創建,但是不需要業務來釋放。
Netty 服務端高併發保護
高併發場景下的 OOM 問題
在 RPC 調用時,如果客戶端併發連接數過多,服務端又沒有針對併發連接數的流控機制,一旦服務端處理慢,就很容易發生批量超時和斷連重連問題。
以 Netty HTTPS 服務端爲例,典型的業務組網示例如下所示:
客戶端採用 HTTP 連接池的方式與服務端進行 RPC 調用,單個客戶端連接池上限爲 200,客戶端部署了 30 個實例,而服務端只部署了 3個實例。在業務高峯期,每個服務端需要處理 6000 個 HTTP 連接,當服務端時延增大之後,會導致客戶端批量超時,超時之後客戶端會關閉連接重新發起connect 操作,在某個瞬間,幾千個 HTTPS 連接同時發起 SSL 握手操作,由於服務端此時也處於高負荷運行狀態,就會導致部分連接 SSL握手失敗或者超時,超時之後客戶端會繼續重連,進一步加重服務端的處理壓力,最終導致服務端來不及釋放客戶端 close 的連接,引起NioSocketChannel 大量積壓,最終 OOM。
通過客戶端的運行日誌可以看到一些 SSL 握手發生了超時,示例如下:
服務端並沒有對客戶端的連接數做限制,這會導致儘管 ESTABLISHED 狀態的連接數並不會超過 6000 上限,但是由於一些 SSL連接握手失敗,再加上積壓在服務端的連接並沒有及時釋放,最終引起了 NioSocketChannel 的大量積壓。
Netty HTTS 併發連接數流控
在服務端增加對客戶端併發連接數的控制,原理如下所示:
基於 Netty 的 Pipeline 機制,可以對 SSL 握手成功、SSL 連接關閉做切面攔截(類似於 Spring 的 AOP機制,但是沒采用反射機制,性能更高),通過流控切面接口,對 HTTPS 連接做計數,根據計數器做流控,服務端的流控算法如下:
- 獲取流控閾值。
- 從全局上下文中獲取當前的併發連接數,與流控閾值對比,如果小於流控閾值,則對當前的計數器做原子自增,允許客戶端連接接入。
- 如果等於或者大於流控閾值,則拋出流控異常給客戶端。
- SSL 連接關閉時,獲取上下文中的併發連接數,做原子自減。
在實現服務端流控時,需要注意如下幾點:
- 流控的 ChannelHandler 聲明爲 @ChannelHandler.Sharable,這樣全局創建一個流控實例,就可以在所有的 SSL 連接中共享。
- 通過 userEventTriggered 方法攔截 SslHandshakeCompletionEvent 和 SslCloseCompletionEvent 事件,在 SSL 握手成功和 SSL 連接關閉時更新流控計數器。
- 流控並不是單針對 ESTABLISHED 狀態的 HTTP 連接,而是針對所有狀態的連接,因爲客戶端關閉連接,並不意味着服務端也同時關閉了連接,只有 SslCloseCompletionEvent 事件觸發時,服務端才真正的關閉了 NioSocketChannel,GC 纔會回收連接關聯的內存。
- 流控 ChannelHandler 會被多個 NioEventLoop 線程調用,因此對於相關的計數器更新等操作,要保證併發安全性,避免使用全局鎖,可以通過原子類等提升性能。
總結
其它的防內存泄漏措施
NioEventLoop
執行它的 execute(Runnable task) 以及定時任務相關接口時,如果任務執行耗時過長、任務執行頻度過高,可能會導致任務隊列積壓,進而引起OOM,建議業務在使用時,對 NioEventLoop 隊列的積壓情況進行採集和告警。
客戶端連接池
業務在初始化連接池時,如果採用每個客戶端連接對應一個 EventLoopGroup 實例的方式,即每創建一個客戶端連接,就會同時創建一個NioEventLoop 線程來處理客戶端連接以及後續的網絡讀寫操作,採用的策略是典型的 1 個 TCP 連接對應一個 NIO線程的模式。當系統的連接數很多、堆內存又不足時,就會發生內存泄漏或者線程創建失敗異常。問題示意如下:
優化策略:客戶端創建連接池時,EventLoopGroup 可以重用,優化之後的連接池線程模型如下所示:
內存泄漏問題定位
堆內存泄漏
通過 jmap -dump:format=b,file=xx pid 命令 Dump 內存堆棧,然後使用 MemoryAnalyzer
工具對內存佔用進行分析,查找內存泄漏點,然後結合代碼進行分析,定位內存泄漏的具體原因,示例如下所示:
堆外內存泄漏
建議策略如下:
- 排查下業務代碼,看使用堆外內存的地方是否存在忘記釋放問題。
- 如果使用到了 Netty 的 TLS/SSL/openssl,建議到 Netty 社區查下 BUG 列表,看是否是 - Netty 老版本已知的 BUG,此類 BUG 通過升級 Netty 版本可以解決。
如果上述兩個步驟排查沒有結果,則可以通過 google-perftools 工具協助進行堆外內存分析。
作者簡介
李林鋒,10 年 Java NIO、平臺中間件設計和開發經驗,精通 Netty、Mina、分佈式服務框架、API Gateway、PaaS 等 ,《Netty
進階之路》、《分佈式服務框架原理與實踐》作者。目前在華爲終端應用市場負責業務微服務化、雲化、全球化等相關設計和開發工作。
聯繫方式:新浪微博 Nettying 微信:Nettying
Email:[email protected]
本文爲轉載文章。