dianping
客户端netty写入是否有内存泄露风险
我倒是没有碰到过这种情况。有时也会出现 CAT 服务端机器长时间呆住，但是并没有收到客户端内存泄露的报告。不知道你能不能顺便测试一下这个场景，可以在 debug 状态下，让服务端保持连接但不处理消息，看看客户端不断发消息后，内存的泄露情况。
On Jan 20, 2025, at 19:48, ZaynJiang @.***> wrote:
如果channel一直是不可写入的话，会不会有这个问题 image.png (view on web) https://github.com/user-attachments/assets/1238b613-2b01-4d49-83b9-d970c7453f61 image.png (view on web) https://github.com/user-attachments/assets/6088bfbc-ba4c-4480-9ac7-7f52b30e25ac — Reply to this email directly, view it on GitHub https://github.com/dianping/cat/issues/2362, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASQE7Y6NNSNWSG7SMXEFS32LTO7XAVCNFSM6AAAAABVQFXZLCVHI2DSMVQWIX3LMV43ASLTON2WKOZSG44TSMBUG4YDENA. You are receiving this because you are subscribed to this thread.
我的客户端目前就是cat服务端长时间呆住，我重启服务端后，客户端内存泄漏了，dump客户端，channel是active和open的，但是是不可写的入的，这个checker会一直执行导致taskqueue无限增长，怀疑nioeventloop selector run线程无法消费数据，导致buffer无法恢复至channel一直被流量控制不可写入。目前还没成功再次模拟出现这种场景了，如图，应用进程无法fullgc的时候，这个taskqueue对象非常多
我倒是没有碰到过这种情况。有时也会出现 CAT 服务端机器长时间呆住，但是并没有收到客户端内存泄露的报告。不知道你能不能顺便测试一下这个场景，可以在 debug 状态下，让服务端保持连接但不处理消息，看看客户端不断发消息后，内存的泄露情况。 …
如果isWritable() 是 false，多 flush 几次应该没有负面影响。task queue 中消息应该是之前的写入的，如果 isWritable() 一直返回 false，就不会有新消息写入。
时间久了，忘了 isWritable() 返回 false 的原因了，不妨你去跟踪一下 netty 内部代码
On Jan 21, 2025, at 09:25, ZaynJiang @.***> wrote:
我的客户端目前就是cat服务端长时间呆住，我重启服务端后，客户端内存泄漏了，dump客户端，channel是active和open的，但是是不可写的入的，这个checker会一直执行导致taskqueue无限增长，怀疑nioeventloop selector run线程无法消费数据，导致buffer无法恢复至channel一直被流量控制不可写入。目前还没成功再次模拟出现这种场景了，如图，应用进程无法fullgc的时候，这个taskqueue对象非常多
image.png (view on web) https://github.com/user-attachments/assets/c81cff75-b509-4103-a331-5659cce6af89 我倒是没有碰到过这种情况。有时也会出现 CAT 服务端机器长时间呆住，但是并没有收到客户端内存泄露的报告。不知道你能不能顺便测试一下这个场景，可以在 debug 状态下，让服务端保持连接但不处理消息，看看客户端不断发消息后，内存的泄露情况。 … x-msg://2/# — Reply to this email directly, view it on GitHub https://github.com/dianping/cat/issues/2362#issuecomment-2603445461, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASQE75AM3VN5I2PRCQURXT2LWO2JAVCNFSM6AAAAABVQFXZLCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBTGQ2DKNBWGE. You are receiving this because you commented.
如果isWritable() 是 false，多 flush 几次应该没有负面影响。task queue 中消息应该是之前的写入的，如果 isWritable() 一直返回 false，就不会有新消息写入。
时间久了，忘了 isWritable() 返回 false 的原因了，不妨你去跟踪一下 netty 内部代码 …
isWritable() false我看了下是netty的outboundBuffer写入数量超过了64Kb数据就会流量控制，置为false。task queue的消息全是AbstractChannelHandlerContext中的invokeFlushTask对象，这个入口就是cat中的ChannelManager的checker，确实内存异常增长是在我重启服务端之后，这个可能导致channel被激活？。我想到可能是就是selector异常了，netty只会通过selector事件去write吗，只能再研究研究netty了，现在生产应用比较多，还是有点担心以后重启cat搞出事故
应该不太会，CAT 在大厂中广泛使用，并没有碰到过类似问题。
On Jan 21, 2025, at 10:07, ZaynJiang @.***> wrote:
如果isWritable() 是 false，多 flush 几次应该没有负面影响。task queue 中消息应该是之前的写入的，如果 isWritable() 一直返回 false，就不会有新消息写入。
时间久了，忘了 isWritable() 返回 false 的原因了，不妨你去跟踪一下 netty 内部代码 … x-msg://3/# isWritable() false我看了下是netty的outboundBuffer写入数量超过了64Kb数据就会流量控制，置为false。task queue的消息全是AbstractChannelHandlerContext中的invokeFlushTask对象，这个入口就是cat中的ChannelManager的checker，确实内存异常增长是在我重启服务端之后，这个可能导致channel被激活？。我想到可能是就是selector异常了，netty只会通过selector事件去write吗，只能再研究研究netty了，现在生产应用比较多，还是有点担心以后重启cat搞出事故
image.png (view on web) https://github.com/user-attachments/assets/3ed81ba9-85a1-4e20-a90c-b26d8509afab — Reply to this email directly, view it on GitHub https://github.com/dianping/cat/issues/2362#issuecomment-2603480623, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASQE73F6REZK43BDCPLA3L2LWTUNAVCNFSM6AAAAABVQFXZLCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBTGQ4DANRSGM. You are receiving this because you commented.