Venus 日志从 March, 2012

Venus 2.0.4 Released

本次升级主要针对接收socket传输的buffer进行了可动态调整buffer的大小

原因:

每次从socket channel中读取完成一个数据包的时候,将动态调整每次接收到packet的平均大小,根据当前的buffer与平均值,来进行决策是是否需要收缩当前连接接收的buffer。

主要目的是为了解决,当前连接在接收一个非常大数据包(接近venus启动的时候设定的buffer的最大值: -Dtookit.packet.max=2*1024*1024 ,默认2M)buffer将会自动扩容来容纳数据,在之前的版本,该buffer始终会保留在这个connection上,除非该connection被关闭才会释放这个buffer。这样会带来一个问题:久而久之所有连接上的buffer都可能达到 最大值2M,占内存非常恐怖,可以计算一下: 连接数 * 2M ... 很容易造成内存不足 导致 OOM的问题。

具体策略

因此需要采用动态调整Buffer的大小:

本次改动增加一个自动收缩的参数:-Dtookit.packet.shrink=10*1024 ,我们当这个为X(默认10k),新一轮在从socket 的缓冲区读取数据的时候,会检测当前buffer的大小,

  1. X :表示 为自动收缩
  2. A :表示数据包的平均大小
  3. M:表示数据包的最大限制值
  4. C:表示当前数据包大小
  5. B:表示当前Buffer大小

下面几点说明以上几个参数变化的条件:

  • C 如果大于 M,则将关闭当前socket连接
  • C 如果大于 B,则扩容 B 的大小,达到能够容纳 C 
  • B 如果大于 X,那么将会收缩到 这个设定的值 X,如果平均值 A 也超过 X ,那么还是根据具体的业务情况来在启动脚本中调节 X 这个参数的数值,可以适当调大
  • B 如果小于 X,那么将会判断当前Buffer 是否大于A的4倍,如果大于则收缩成2倍的A: 2 × A,否则不做收缩
Venus 2.0.3 Released

bug Fix列表:

1、修复连接池出现网络异常以后无法修复连接问题,提升了虚拟连接池心跳检测可靠机制。

改善的地方:

1、客户端每个Remote下,每个地址将开启成一个阻塞Pool、非阻塞Pool。如果该remote配置多个地址组成,则将会形成一个虚拟Pool

2、增加客户端的性能日志输出:

log4j.xml配置
    <logger name="venus.service.performance" additivity="false">
        <level value="debug"/>


	<!-- 这儿自己设置需要输出的地方 -->
        <appender-ref ref="PROJECT-CONSOLE"/>
    </logger>
日志输出形式
2012-03-23 14:18:42,984 DEBUG service.performance - [0,0]ms api=HelloService.sayAsyncHello
2012-03-23 14:18:42,984 DEBUG service.performance - [0,0]ms api=HelloService.sayAsyncHello
2012-03-23 14:18:42,984 DEBUG service.performance - [0,0]ms api=HelloService.sayAsyncHello
2012-03-23 14:18:42,984 DEBUG service.performance - [0,0]ms api=HelloService.sayAsyncHello

解释:[0,0]ms api=HelloService.sayAsyncHello 

格式:[x,y]ms api=apiName,其中x表示获取一个连接的时间,y表示客户端发起一个请求,并且收到服务端反馈总共消耗的时间,这2个单位都是毫秒,apiName表示本次请求的api方法