You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
47 lines
2.1 KiB
Markdown
47 lines
2.1 KiB
Markdown
2 years ago
|
# Netty
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
## Netty调优
|
||
|
|
|
||
|
|
### Netty调优 - 内存调优
|
||
|
|
#### 1. netty客户端连接池泄漏问题复现及原因解析
|
||
|
|
- 问题复现: 生产环境使用 netty 作为客户端通信框架, 在客户端创建一个 tcp 连接池, 随着也无压力的上升, 在高峰期出现OOM问题, 需要重启才能恢复
|
||
|
|
|
||
|
|
- 参考: com.baiye.case2
|
||
|
|
|
||
|
|
- Bootstrap 不是线程安全的
|
||
|
|
- 真正的逻辑是 bossGroup 来进行处理的
|
||
|
|
|
||
|
|
- **总结**：编码规范问题, 注意客户端连接建立的编写, 关闭chanel的问题
|
||
|
|
|
||
|
|
### 2. netty内存池泄漏问题复现及排查解析
|
||
|
|
- 问题复现: 服务端使用 netty 作为通信框架, 负责消息接入和路由转发, 在功能测试时没有发现问题, 转性能测试后, 运行一段时间发现内存分配异常, 服务端无法接收请求消息, 系统吞吐量为0
|
||
|
|
- 当消息进来的时候, Netty给他分配的内存没有释放,最终导致了内存泄漏
|
||
|
|
- ByteBuf申请和释放场景分析
|
||
|
|
- 基于内存池的请求 ByteBuf
|
||
|
|
- 我们建议在使用 ServerHandler 时候实际使用 SimpleChannelInboundHandler , 不会存在内存泄露问题
|
||
|
|
- 基于非内存池请求的 ByteBuf (不推荐), 还是要自己释放
|
||
|
|
- 基于内存池的响应 ByteBuf
|
||
|
|
- 基于非内存池的响应 ByteBuf (不推荐) 还是要自己释放
|
||
|
|
|
||
|
|
- **总结**: ServerHandler 选用 SimpleChannelInboundHandler 来规避内存泄漏问题
|
||
|
|
|
||
|
|
### 3. netty 内存池 的性能对比
|
||
|
|
- 4.x 引入 内存池机制, 对netty的提升很大
|
||
|
|
- com.baiye.case3.ByteBufPerformance 池化代码测试
|
||
|
|
- netty 内存池很大程度上提升了系统性能, 但是无用则会代理内存泄漏问题, 由于内存的申请和释放可能由Netty框架隐形完成, 所以增加了内存管理复杂度,所以必须深入理解ByteBuf的申请和释放机制,以免误用
|
||
|
|
|
||
|
|
- **总结**: 使用 4.x 提供的池化技术 PooledByteBufAllocator , 提升性能
|
||
|
|
|
||
|
|
### 4. ByteBuf 故障排查及优化 - HTTP 响应 Body 获取异常
|
||
|
|
- HTTP协议栈 ByteBuf 使用问题
|
||
|
|
- netty 解决好 HTTP 协议的问题, 就可以当 Tomcat 进行使用
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
### Netty调优 - 并发调优
|
||
|
|
|
||
|
|
|
||
|
|
|