| 注册
请输入搜索内容

热门搜索

Java Linux MySQL PHP JavaScript Hibernate jQuery Nginx
OnitaC01
8年前发布

Netty的优化备记

   <h3><strong>1.当心“日志隐形杀手”</strong></h3>    <p>通常情况下,大家都知道不能在Netty的I/O线程上做执行时间不可控的操作,例如访问数据库、发送Email等。但是有个常用但是非常危险的操作却容易被忽略,那便是记录日志。</p>    <p>通常,在生产环境中,需要实时打印接口日志,其它日志处于ERROR级别,当推送服务发生I/O异常之后,会记录异常日志。如果当前磁盘的WIO比较高,可能会发生写日志文件操作被同步阻塞,阻塞时间无法预测。这就会导致Netty的NioEventLoop线程被阻塞,Socket链路无法被及时关闭、其它的链路也无法进行读写操作等。</p>    <p>以最常用的log4j为例,尽管它支持异步写日志(AsyncAppender),但是当日志队列满之后,它会同步阻塞业务线程,直到日志队列有空闲位置可用,相关代码如下:</p>    <pre>  <code class="language-javascript">synchronized (this.buffer) {        while (true) {          int previousSize = this.buffer.size();          if (previousSize < this.bufferSize) {            this.buffer.add(event);            if (previousSize != 0) break;            this.buffer.notifyAll(); break;          }          boolean discard = true;          if ((this.blocking) && (!Thread.interrupted()) && (Thread.currentThread() != this.dispatcher)) //判断是业务线程          {            try            {              this.buffer.wait();//阻塞业务线程              discard = false;            }            catch (InterruptedException e)            {              Thread.currentThread().interrupt();            }  }</code></pre>    <p>类似这类BUG具有极强的隐蔽性,往往WIO高的时间持续非常短,或者是偶现的,在测试环境中很难模拟此类故障,问题定位难度非常大。这就要求读者在平时写代码的时候一定要当心,注意那些隐性地雷。</p>    <h3><strong>2.TCP参数优化</strong></h3>    <p>常用的TCP参数,例如TCP层面的接收和发送缓冲区大小设置,在Netty中分别对应ChannelOption的SO_SNDBUF和SO_RCVBUF,需要根据推送消息的大小,合理设置,对于海量长连接,通常32K是个不错的选择。</p>    <p>另外一个比较常用的优化手段就是软中断,如图所示:如果所有的软中断都运行在CPU0相应网卡的硬件中断上,那么始终都是cpu0在处理软中断,而此时其它CPU资源就被浪费了,因为无法并行的执行多个软中断。</p>    <p>大于等于2.6.35版本的Linux kernel内核,开启RPS,网络通信性能提升20%之上。RPS的基本原理:根据数据包的源地址,目的地址以及目的和源端口,计算出一个hash值,然后根据这个hash值来选择软中断运行的cpu。从上层来看,也就是说将每个连接和cpu绑定,并通过这个hash值,来均衡软中断运行在多个cpu上,从而提升通信性能。</p>    <h3><strong>3.JVM参数</strong></h3>    <p>最重要的参数调整有两个:</p>    <p>-Xmx:JVM最大内存需要根据内存模型进行计算并得出相对合理的值;</p>    <p>GC相关的参数: 例如新生代和老生代、永久代的比例,GC的策略,新生代各区的比例等,需要根据具体的场景进行设置和测试,并不断的优化,尽量将Full GC的频率降到最低。</p>    <h3><strong>4.内存池</strong></h3>    <p>推送服务器承载了海量的长链接,每个长链接实际就是一个会话。如果每个会话都持有心跳数据、接收缓冲区、指令集等数据结构,而且这些实例随着消息的处理朝生夕灭,这就会给服务器带来沉重的GC压力,同时消耗大量的内存。</p>    <p>最有效的解决策略就是使用内存池,每个NioEventLoop线程处理N个链路,在线程内部,链路的处理时串行的。假如A链路首先被处理,它会创建接收缓冲区等对象,待解码完成之后,构造的POJO对象被封装成Task后投递到后台的线程池中执行,然后接收缓冲区会被释放,每条消息的接收和处理都会重复接收缓冲区的创建和释放。如果使用内存池,则当A链路接收到新的数据报之后,从NioEventLoop的内存池中申请空闲的ByteBuf,解码完成之后,调用release将ByteBuf释放到内存池中,供后续B链路继续使用。</p>    <p> </p>    <p> </p>    <p> </p>    <p>来自:http://blog.edagarli.com/2016/09/24/Netty的优化备记/</p>    <p> </p>    
 本文由用户 OnitaC01 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
 转载本站原创文章,请注明出处,并保留原始链接、图片水印。
 本站是一个以用户分享为主的开源技术平台,欢迎各类分享!
 本文地址:https://www.open-open.com/lib/view/open1474858236863.html
Netty 网络工具包