Dubbo性能调优

性能优化

dubbo序列化+netty

目前客户端数据接口的场景99%为1k数据量以内,根据各种协议性能测试对比分析,选用dubbo序列化与netty传输方式可达到性能最大化,以下为阿里官方给出的性能测试结果,提供参考:

1k string 场景:

image

netty线程池配置

经过线上生产环境压力测试(服务器48核,由于CPU为AMD,单核处理能力偏低),评估后最优线程数配置为500,采用固定大小的线程池,计算密集型服务可最大分配8核,IO密集型服务最大分配4核。

线上2016年1月31日系统无法接入请求故障维持4个多小时,排查后发现后端BOSS系统处理能力有限,且响应时间过长,导致线程满负荷状态下切配置队列的情况下,线程池打满后,请求全部进入队列排队,请求与处理能力严重失衡,导致队列很快也被打满,所有请求无法接入,服务呈现不可用状态,再经过分析后,决定去掉队列且将连接超时时间由12秒缩短为5秒,舍弃BOSS系统响应超过5秒的请求,对用户侧进行友好提示,保证BOSS响应低于5秒的用户可正常使用。

配置策略:

1
<dubbo:protocol name="dubbo" port="${dubbo.protocol.port}" server="netty" client="netty" serialization="dubbo" charset="UTF-8" threadpool="fixed" threads="500" queues="0" buffer="8192" accepts="0" payload="8388608" />

zookeeper注册中心

支持基于网络的集群方式,适合生产环境服务数量较多环境下使用,且配置使用方式简单,可靠性高。

1
<dubbo:registry protocol="zookeeper" address="${dubbo.registry.address}" file="${user.home}/.dubbo/${dubbo.registry.file}"/>

特别注意: zookeeper采用集群方式保证注册中心服务的高可用与高性能,部署节点数应为奇数。

JVM配置优化

  1. 方案一:通用方式

    1
    2
    3
    4
    5
    #JAVA_HOME=/application/search/vertical-search/vertical-search/jdk1.7.0_51
    VERTICAL_SEARCH_LOG="/data/gclog/"
    #VERTICAL_SEARCH_CONF="/application/search/vertical-search/conf"
    JAVA_OPTS='-server -verbose:gc -Xms6000m -Xmx6000m -Xmn2000m -XX:PermSize=300m -XX:MaxPermSize=300m -Xss256k -XX:NewSize=500m -XX:MaxNewSize=500m -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=16 -XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=5000 -XX:+UseParNewGC -XX:+DisableExplicitGC -Xloggc:${VERTICAL_SEARCH_LOG}/logs/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${VERTICAL_SEARCH_LOG}/logs/HeapDumpOnOutOfMemoryError.log -XX:+DisableExplicitGC -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -DVERTICAL_SEARCH_LOG=${VERTICAL_SEARCH_LOG}'
  2. 方案二:又有改进了,上面方法不太好,因为没有用到救助空间,所以年老代容易满,CMS执行会比较频繁。我改善了一下,还是用救助空间,但是把救助空间加大,这样也不会有promotion failed。具体操作上,32位Linux和64位Linux好像不一样,64位系统似乎只要配置MaxTenuringThreshold参数,CMS还是有暂停。为了解决暂停问题和promotion failed问题,最后我设置-XX:SurvivorRatio=1 ,并把MaxTenuringThreshold去掉,这样即没有暂停又不会有promotoin failed,而且更重要的是,年老代和永久代上升非常慢(因为好多对象到不了年老代就被回收了),所以CMS执行频率非常低,好几个小时才执行一次,这样,服务器都不用重启了。

    1
    2
    3
    4
    #JAVA_HOME=/application/search/vertical-search/vertical-search/jdk1.7.0_51
    VERTICAL_SEARCH_LOG="/data/gc"
    JAVA_OPTS='-server -Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:${VERTICAL_SEARCH_LOG}/logs/gc.log'
  3. 方案三:64位jdk参考设置,年老代涨得很慢,CMS执行频率变小,CMS没有停滞,也不会有promotion failed问题,内存回收得很干净.

    1
    2
    3
    4
    #JAVA_HOME=/application/search/vertical-search/vertical-search/jdk1.7.0_51
    VERTICAL_SEARCH_LOG="/data/gc"
    JAVA_OPTS='-server -Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:${VERTICAL_SEARCH_LOG}/logs/gc.log'
  4. 方案四:docker tomcat jvm优化方案:

    1
    -Xmx2048M -Xms2048M -Xmn512M -XX:PermSize=320M -XX:MaxPermSize=320M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC

Never Give Up!