共计 2952 个字符，预计需要花费 8 分钟才能阅读完成。
这篇文章将为大家详细讲解有关如何实现 RocketMQ 性能压测分析，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
一 机器部署 1.1 机器组成
1 台 nameserver
1 台 broker 异步刷盘
2 台 producer
2 台 consumer
1.2 硬件配置
CPU 两颗 x86_64cpu, 每颗 cpu12 核，共 24 核
内存 48G
网卡 千兆网卡
磁盘 除 broker 机器的磁盘是 RAID10，共 1.1T，其他都是普通磁盘约 500G
1.3 部署结构
橙色箭头为数据流向，黑色连接线为网络连接
1.4 内核参数
broker 是一个存储型的系统，针对磁盘读写有自己的刷盘策略，大量使用文件内存映射，文件句柄和内存消耗量都比较巨大。因此，系统的默认设置并不能使 RocketMQ 发挥很好的性能，需要对系统的 pagecache，内存分配，I/ O 调度，文件句柄限制做一些针对性的参数设置。
系统 I / O 和虚拟内存设置
echo vm.overcommit_memory=1 /etc/sysctl.conf
echo vm.min_free_kbytes=5000000 /etc/sysctl.conf
echo vm.drop_caches=1 /etc/sysctl.conf
echo vm.zone_reclaim_mode=0 /etc/sysctl.conf
echo vm.max_map_count=655360 /etc/sysctl.conf
echo vm.dirty_background_ratio=50 /etc/sysctl.conf
echo vm.dirty_ratio=50 /etc/sysctl.conf
echo vm.page-cluster=3 /etc/sysctl.conf
echo vm.dirty_writeback_centisecs=360000 /etc/sysctl.conf
echo vm.swappiness=10 /etc/sysctl.conf
系统文件句柄设置
echo ulimit -n 1000000 /etc/profile
echo admin hard nofile 1000000 /etc/security/limits.conf
系统 I / O 调度算法
deadline
1.5 JVM 参数
采用 RocketMQ 默认设置
-server -Xms4g -Xmx4g -Xmn2g -XX:PermSize=128m -XX:MaxPermSize=320m -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+CMSClassUnloadingEnabled -XX:SurvivorRatio=8 -XX:+DisableExplicitGC -verbose:gc -Xloggc:/root/rocketmq_gc.log -XX:+PrintGCDetails -XX:-OmitStackTraceInFastThrow
二 性能评测 2.1 评测目的
压测单机 TPS，评估单机容量
2.2 评测指标
最高的 TPS 不代表最适合的 TPS，必须在 TPS 和系统资源各项指标之间取得一个权衡，系统资源快达到极限，但尚能正常运转，此时的 TPS 是比较合适的。比如 ioutil 最好不要超过 75%,cpu load 最好不超过总的核数或者太多，没有发生频繁的 swap 导致较大的内存颠簸。所以不能只关注 TPS，同时要关注以下指标：
消息：TPS
cpu：load,sy,us
内存：useed,free,swap,cache,buffer
I/O：iops,ioutil, 吞吐量 (数据物理读写大小 / 秒)
网络：网卡流量
2.3 评测方式
两台 producer 起等量线程，不间断的向 broker 发送大小为 2K 的消息，2K 消息意味着 1000 个字符，这个消息算比较大了，完全可以满足业务需要。
2.4 评测结果
TPS 比较高
经过长时间测试和观察，单个 borker TPS 高达 16000，也就是说服务器能每秒处理 16000 条消息，且消费端及时消费，从服务器存储消息到消费端消费完该消息平均时延约为 1.3 秒，且该时延不会随着 TPS 变大而变大，是个比较稳定的值。
Broker 稳定性较高
两台 producer 一共启动 44 个线程 10 个小时不停发消息，broker 非常稳定，这可简单意味着实际生产环境中可以有几十个 producer 向单台 broker 高频次发送消息，但是 broker 还会保持稳定。在这样比较大的压力下，broker 的 load 最高才到 3（24 核的 cpu），有大量的内存可用。
而且，连续 10 几小时测试中，broker 的 jvm 非常平稳，没有发生一次 fullgc，新生代 GC 回收效率非常高，内存没有任何压力，以下是摘自 gclog 的数据：
2014-07-17T22:43:07.407+0800: 79696.377: [GC2014-07-17T22:43:07.407+0800: 79696.377: [ParNew: 1696113K- 18686K(1887488K), 0.1508800 secs] 2120430K- 443004K(3984640K), 0.1513730 secs] [Times: user=1.36 sys=0.00, real=0.16 secs]
新生代大小为 2g，回收前内存占用约为 1.7g，回收后内存占用 17M 左右，回收效率非常高。
关于磁盘 IO 和内存
平均单个物理 IO 耗时约为 0.06 毫秒，IO 几乎没有额外等待，因为 await 和 svctm 基本相等。整个测试过程，没有发生磁盘物理读，因为文件映射的关系，大量的 cached 内存将文件内容都缓存了，内存还有非常大的可用空间。
系统的性能瓶颈
TPS 到达 16000 后，再就上不去了，此时千兆网卡的每秒流量约为 100M，基本达到极限了，所以网卡是性能瓶颈。不过，系统的 IOUTIL 最高已经到达 40% 左右了，这个数字已经不低了，所以即使网络流量增加，但是系统 IO 指标可能已经不健康了，总体来看，单机 16000 的 TPS 是比较安全的值。
以下是各项指标的趋势
TPS
TPS 最高可以压倒 16000 左右，再往上压，TPS 有下降趋势
内存
内存非常平稳，总量 48G，实际可用内存非常高
没有发生 swap 交换，不会因为频繁访问磁盘导致系统性能颠簸
大量内存被用来作为文件缓存，见 cached 指标，极大的避免了磁盘物理读
磁盘吞吐量
随着线程数增加，磁盘物理 IO 每秒数据读写大约为 70M 左右
IO 百分比
随着线程数增加，IO 百分比最后稳定在 40% 左右，这个数字可以接受
关于“如何实现 RocketMQ 性能压测分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
