消息中间件学习总结（4）——RocketMQ之RocketMQ 迈入50万TPS消息俱乐部

前言

消息团队一直致力于RocketMQ的性能优化，双十一前进行了低延时（毛刺）优化，保障了双十一万亿消息的流转如丝般顺滑，在2016年双十一种，MetaQ以接近万亿的消息总量支撑着全集团数千个应用，在系统解耦、削峰填谷、数据库同步、位点回滚消费等多种业务场景中，MetaQ都有精彩、稳定的表现。高可用低延迟，高并发抗堆积，2016双11的MetaQ真正做到了如丝般顺滑。

而最近通过对性能的持续优化，在RocketMQ最新的中小消息TPS已达47万，本人在F43机型上自测时TPS峰值为57万TPS，所以取了这么一个标题。

RocketMQ高性能优化探索

本章节简单介绍下在优化RocketMQ过程中用到的方法和技巧。部分方法在消息领域提升不明显却带来了编码和运维的复杂度，这类方法虽然最终没有利用起来，也在下面做了介绍供大家参考。

Java篇

在接触到内核层面的性能优化之前，Java层面的优化需要先做起来。有时候灵机一动的优化方法需要实现Java程序来进行测试，注意测试的时候需要在排除其他干扰的同时充分利用JVM的预热(JIT)特性。推荐使OpenJDK开发的基准测试(Benchmark)工具JMH。

JVM停顿

影响Java应用性能的头号大敌便是JVM停顿，说起停顿，大家耳熟能详的便是GC阶段的STW(Stop the World)，除了GC，还有很多其他原因，如下图所示。

当怀疑我们的Java应用受停顿影响较大时，首先需要找出停顿的类型，下面一组JVM参数可以输出详细的安全点信息：

-XX:+LogVMOutput -XX:LogFile=/dev/shm/vm.log 
-XX:+PrintGCApplicationStoppedTime -XX:+PrintSafepointStatistics  
-XX:PrintSafepointStatisticsCount=1 -XX:+PrintGCApplicationConcurrentTime

在RocketMQ的性能测试中，发现存在大量的RevokeBias停顿，偏向锁主要是消除无竞争情况下的同步原语以提高性能，但考虑到RocketMQ中该场景比较少，便通过-XX:-UseBiasedLocking关闭了偏向锁特性。

停顿有时候会让我们的StopWatch变得很不精确，有一段时间经常被StopWatch误导，观察到一段代码耗时异常，结果花时间去优化也没效果，其实不是这段代码耗时，只是在执行这段代码时发生了停顿。停顿和动态编译往往是性能测试的两大陷阱。

GC

GC将Java程序员从内存管理中解救了出来，但也对开发低延时的Java应用带来了更多的挑战。对GC的优化个人认为是一项调整参数的工作，垃圾收集方面最值得关注的两个性能属性为吞吐量和延迟，对GC进行优化往往是寻求吞吐量和延迟上的折衷，没办法鱼和熊掌兼得。

RocketMQ通过GC调优后最终采取的GC参数如下所示，供大家参考。

-server -Xms8g -Xmx8g -Xmn4g
-XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:G1ReservePercent=25 
-XX:InitiatingHeapOccupancyPercent=30 -XX:SoftRefLRUPolicyMSPerMB=0 
-XX:SurvivorRatio=8 -XX:+DisableExplicitGC
-verbose:gc -Xloggc:/dev/shm/mq_gc_%p.log -XX:+PrintGCDetails 
-XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime
-XX:+PrintAdaptiveSizePolicy
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=30m

可以看出，我们最终全部切换到了G1，16年双十一线上MetaQ集群采用的也是这一组参数，基本上GC时间能控制在20ms以内（一些超大的共享集群除外）。

对于G1，官方推荐使用该-XX:MaxGCPauseMillis设置目标暂停时间，不要手动指定-Xmn和-XX:NewRatio，但我们在实测中发现，如果指定过小的目标停顿时间(10ms)，G1会将新生代调整为很小，导致YGC更加频繁，老年代用得更快，所有还是手动指定了-Xmn为4g，在GC频率不高的情况下完成了10ms的目标停顿时间，这里也说明有时候一些通用的调优经验并不适用于所有的产品场景，需要更多的测试才能找到最合适的调优方法，往往需要另辟蹊径。

同时也分享下我们在使用CMS时遇到的一个坑，-XX:UseConcMarkSweepGC在使用CMS收集器的同时默认在新生代使用ParNew， ParNew并行收集垃圾使用的线程数默认值更机器cpu数(1个节点，即为支持NUMA 内存篇

可以将Linux内存分为以下三类：

《如丝般顺滑—METAQ2016双11总结》一文中比较详细地介绍了访存过程中需要注意的地方，同时给出了消除访问匿名内存和PageCache的方法。本章节介绍一些其它需要注意的地方。

页错误

我们知道，为了使用更多的内存地址空间切更加有效地管理存储器，操作系统提供了一种对主存的抽象概念——虚拟存储器(VM)，有了虚拟存储器，就必然需要有从虚拟到物理的寻址。进程在分配内存时，实际上是通过VM系统分配了一系列虚拟页，此时并未涉及到真正的物理页的分配。当进程真正地开始访问虚拟内存时，如果没有对应的物理页则会触发缺页异常，然后调用内核中的缺页异常处理程序进行的内存回收和分配。

页错误分为两种：

1. Major Fault, 当需要访问的内存被swap到磁盘上了，这个时候首先需要分配一块内存，然后进行disk io将磁盘上的内容读回道内存中，这是一系列代价比较昂贵的操作。
2. Minor Fault, 常见的页错误，只涉及页分配。

为了提高访存的高效性，需要观察进程的页错误信息，以下命令都可以达到该目的：

1. ps -o min_flt,maj_flt 
2. sar -B

如果观察到Major Fault比较高，首先要确认系统参数vm.swappiness是否设置恰当，建议在机器内存充足的情况下，设置一个较小的值(0或者1)，来告诉内核尽可能地不要利用磁盘上的swap区域，0和1的选择原则如下：

切记不要在2.6.32以后设置为0，这样会导致内核关闭swap特性，内存不足时不惜OOM也不会发生swap，前端时间也碰到过因swap设置不当导致的故障。

另一方面，避免触发页错误，内存频繁的换入换出，还有以下手段可以采用：

1. -XX:+AlwaysPreTouch，顾名思义，该参数为让JVM启动时将所有的内存访问一遍，达到启动后所有内存到位的目的，避免页错误。
2. 对于我们自行分配的堆外内存，或者mmap从文件映射的内存，我们可以自行对内存进行预热，有以下四种预热手段，第一种不可取，后两种是最快的。

3. 即使对内存进行了预热，当内存不够时，后续还是会有一定的概率被换出，如果希望某一段内存一直常驻，可以通过mlock/mlockall系统调用来将内存锁住，推荐使用JNA来调用这两个接口。不过需要注意的是内核一般不允许锁定大量的内存，可通过以下命令来增加可锁定内存的上限。

   echo '* hard memlock      unlimited' >> /etc/security/limits.conf
   echo '* soft memlock      unlimited' >> /etc/security/limits.conf
   

Huge Page

大家都知道，操作系统的内存4k为一页，前文说到Linux有虚拟存储器，那么必然需要有页表(Page Table)来存储物理页和虚拟页之间的映射关系，CPU访问存时首先查找页表来找到物理页，然后进行访存，为了提高寻址的速度，CPU里有一块高速缓存名为ranslation Lookaside Buffer (TLB)，包含部分的页表信息，用于快速实现虚拟地址到物理地址的转换。

但TLB大小是固定的，只能存下小部分页表信息，对于超大页表的加速效果一般，对于4K内存页，如果分配了10GB的内存，那么页表会有两百多万个Entry，TLB是远远放不下这么多Entry的。可通过cpuid查询TLB Entry的个数，4K的Entry一般仅有上千个，加速效果有限。

为了提高TLB的命中率，大多数CPU支持大页，大页分为2MB和1GB，1GB大页是超大内存的不二选择，可通过grep pdpe1gb /proc/cpuinfo | uniq查看CPU是否支持1GB的大页。

开启大页需要配置内核启动参数，hugepagesz=1GB hugepages=10，设置大页数量可通过内核启动参数hugepages或者/proc/sys/vm/nr_hugepages进行设置。

内核开启大页过后，Java应用程序使用大页有以下方法：

• 对于堆内存，有JVM参数可以用：-XX:+UseLargePages
• 如果需要堆外内存，可以通过mount挂载hugetlbfs，mount -t hugetlbfs hugetlbfs /hugepages，然后通过mmap分配大页内存。

可以看出使用大页比较繁琐的，Linux提供透明超大页面 (THP)。THP 是可自动创建、管理和使用超大页面。可通过修改文件/sys/kernel/mm/transparent_hugepage/enabled来关闭或者打开THP。

但大页有一个弊端，如果内存压力大，需要换出时，大页会先拆分成小页进行换出，需要换入时再合并为大页，该过程会加重CPU的压力。LinkedIn有位工程师有一个比较有趣的尝试，在内存压力小的时候启用THP，在内存压力大的时候关闭THP，通过这种动态调整达到最优性能，可以看看他的论文：Ensuring High-performance of Mission-critical Java Applications in Multi-tenant Cloud Platforms。

网卡篇

网卡性能诊断工具是比较多的，有ethtool, ip, dropwatch, netstat等，RocketMQ尝试了网卡中断和中断聚合两方面的优化手段。

网卡中断

这方面的优化首先便是要考虑是否需要关闭irqbalance，它用于优化中断分配，通过自动收集系统数据来进行中断负载，同时还会综合考虑节能等因素。但irqbalance有个缺点是会导致中断自动漂移，造成不稳定的现象，在高性能的场合建议关闭。

关闭irqbalance后，需要对网卡的所有队列进行CPU绑定，目前的网卡都是由多队列组成，如果所有队列的中断仅有一个CPU进行处理，难以利用多核的优势，所以可以对这些网卡队列进行CPU一一绑定。

这部分优化对RocketMQ的小消息性能提升有很大的帮助。

中断聚合

中断聚合的思想类似于Group Commit，避免每一帧的到来都触发一次中断，RocketMQ在跑到最大性能时，每秒会触发近20000次的中断，如果可以聚合一部分，对性能还是有一定的提升的。

可以通过ethtool设置网卡的rx-frames-irq和rx-usecs参数来决定凑齐多少帧或者多少时间过后才触发一次中断，需要注意的是中断聚合会带来一定的延迟。

总结

目前RocketMQ最新的性能基准测试中，128字节小消息TPS已达47W，如下图所示：

高性能的RocketMQ可应用于更多的场景，能接管和替代Kafka更多的生态，同时可以更大程度上承受热点问题，在保持高性能的同时，RocketMQ在低延迟方面依然具有领先地位，如下图所示，RocketMQ仅有少量10～50ms的毛刺延迟，Kafka则有不少500～1s的毛刺。

广告时间

RocketMQ目前正在Apache基金会孵化，募集开源爱好者共同参与进来，发展RocketMQ社区，为RocketMQ成为顶级项目添砖加瓦。

1. http://rocketmq.apache.org/
2. https://github.com/apache/incubator-rocketmq/