文章目录
背景
事件中心服务新增定时消息功能：
- 基于 RocketMQ 5.0 的 TimerMessage 特性，作为触发定时消息的机制；
- 事件中心API（pubsub）提供新的定时消息接口，作为定时消息的提交入口；
- 定时消息元数据保存至 TiDB，RocketMQ 内只保存定时消息对应的主键ID；
- 定时消息执行服务消费 RocketMQ 指定 Topic ，调用事件中心回调接口，发送消息至Kafka；
- 为消息保证顺序性，RocketMQ Consumer 使用顺序消费。
定时消息的链路为：定时消息接口（pubsub） --> TiDB、RocketMQ --> 定时消息执行服务(Consumer) --> 定时消息回调接口 --> Kafka
本次压测及调优，只针对定时消息接口、定时消息执行服务(Consumer)、定时消息回调接口。
压测准备
压测意图：
-
测试提交定时消息接口在不同 QPS 时的 RT 情况
-
观测pubsub服务在负载情况下的资源使用情况
-
测试consumer的消费能力、得出消息积压与Consumer数量的比例
-
测试定时消息回调接口的QPS峰值
场景描述：
-
pubsub单实例，最终调整配置和生产环境一致
- limit：8c-8g
- -Xms4G -Xmx4G
-
模拟固定QPS对提交定时消息接口进行压测：
- QPS 1000
- QPS 3000
- QPS 5000
-
堆积一定数量的定时消息：
- 观察Consumer消费速度
- 观察定时消息回调接口RT情况
- 观察pubsub服务资源使用情况
观测指标：
pubsub服务器：
-
机器CPU使用情况
- top -Hp {jvm_pid}
-
查看线程级别 user, system 情况
- 火焰图
-
主机 load
-
GC 情况
- 若没有 gc 日志，用 jstat 临时输出一下
-
内存增长情况
-
线程情况
-
接口耗时（通过压测平台监控查看）
- 99.99% RT
- 平均 RT
定时消息执行服务：
-
consumer TPS
-
consumer 服务监控
- jvm监控
- httpclient监控
- QPS
- RT
-
consumer 主机监控
- cpu
- load
- memory
-
pubsub服务器：
- 机器CPU使用情况
- 内存增长情况
-
消息延迟情况
- 对比数据库期望发送时间和实际发送时间
初步压测结论
-
pubsub服务2c-6g，单实例；Consumer服务2c-6g，单实例
-
定时消息提交接口并发数1000，思考时间为1000ms，模拟QPS为1000的场景，平均RT在好几秒，吞吐量只有200左右
-
单个消费者TPS只有60左右
-
pubsub服务及Consumer服务资源使用率均保持在很低水平
-
pubsub服务young GC频繁
离预期相距甚远，预期是可以承受上万条消息积压仍能保持毫秒级别的误差，所以优化目标为：
- 提升pubsub定时消息接口单实例QPS至3000+，99.99% RT 在200ms内；
- 提升Consumer消费TPS至10000+
排查过程记录
排除中间件及网络因素
在pubsub服务实例上ping TiDB、RocketMQ服务地址，延迟均为5ms内，先排除网络原因。
使用相同的压测脚本，尝试压了测试环境的pubsub服务，测试环境的压测结果很正常，QPS达到预期设置的1000，平均RT在10ms内，测试环境使用的是MySQL，生产环境使用的是新申请的阿里云服务器搭建的TiDB，怀疑是TiDB服务端配置或者其他原因导致影响性能。
将生产环境上pubsub使用的TiDB换为同网络环境的MySQL，压测情况并无变化，排除。
RocketMQ服务在相同网段进行过压测，压测结果正常，排除。
由于测试环境和生产环境压测结果大相径庭，很长一段时间的排查方向都指向了生产环境k8s的网络、组件间的延迟等，于是又把pubsub部署至生产环境的一台物理机上，结果任然保持不变。
客观测试了一下测试环境和生产环境的网络差异：
并发数 1，思考时间 1000ms
测试环境：
生产环境：
分析
每次接口提交，大致产生的跨进程交互如下：
| 内容 | 测试环境耗时 | 生产环境耗时 | |
|---|---|---|---|
| 施压机到pubsub主机 | 0.18 | 0.6 | |
| pubsub主机到tidb，开启事务 | 0.06 | 4.9 | |
| pubsub主机到tidb，运行 sql | 0.06 | 4.9 | |
| pubsub主机到rocketMQ，生产消息 | 0.3 | 4 | |
| pubsub主机到tidb，提交事务 | 0.06 | 4.9 | |
| 总计 | 0.66 | 19.3 | |
| 本场景压测RT平均值 | 7.98 | 40.93 |
结论：
由于测试环境的物理距离问题，天然有至少5倍左右的性能差异，所以测试环境的压测结果超出预期的理想，得益于各组件的网络低延迟，但是生产环境的网络延迟属于正常范围，还需进一步排查。
借助Arthas及Skywalking
使用 Arthas 的 trace 命令，对接口的主要逻辑方法进行耗时追踪：
发现真正执行逻辑的代码只耗时13ms左右，但是执行方法之前，有一个500多ms的耗时。
使用skywalking观察耗时很长的请求，结果如下：
结论相同，在执行SQL前，有一个很长的等待时间，初步定位到问题，怀疑是数据库连接池的问题。
暴露prometheus指标
pom文件中添加：
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
<scope>runtime</scope>
</dependency>
添加配置：
# 对外暴露所有监控指标
management:
endpoints:
web:
exposure:
include: "*"
endpoint:
prometheus:
enabled: true # 激活普罗米修斯
health:
show-details: always # 健康值总是展示细节
metrics:
export:
prometheus:
enabled: true # 指标允许被导出
启动服务后，访问：/actuator/prometheus
可以看到默认连接池最大数量是10，大量并发情况下，获取连接池时，耗费了大量的时间。
修改数据库最大连接池数
场景一至场景四：并发数 500，思考时间 400 ms
场景一
pubbsub 调整内容：
- tomcat 线程数改为 64
- connection 连接池数量改为 10
分析
- cpu 使用率不高，execute 前执行时间较长，怀疑是获取 jdbc connection 时间较长，更改 hikari 连接池数量为 32
- 压测平台与 sk 查看不同，是因为存在请求积压，即等待了一段时间后，才开始被执行
场景二
pubsub 调整内容：
- tomcat 线程数改为 64
- connection 连接池数量改为 32
第一次压测：
第二次压测：
分析：
- 从 skywalking 看执行时间已经明显缩短，应该是增大了 connection 连接数导致
- 第二次执行压测时，性能已明显上升，应该是第一次压测时连接池还没有达到指定数量，都要重新建立连接，导致耗时较长
- cpu 使用率升高，说明线程使用 cpu 的时间多了起来，是正确的优化方向
场景三
pubsub 调整内容：
- tomcat 线程数改为 64
- connection 连接池数量改为 64
分析：
- 用在等待连接方面的耗时几乎已经没有
- cpu 还有一定空闲资源，进一步增大线程数和对应的连接数
场景四
pubsub 调整内容：
- tomcat 线程数改为 128
- connection 连接池数量改为 128
分析：
- cpu 已到达瓶颈，调整线程数量收益应该不太明显了
- 这时调整 gc 相关参数应该会有些收益
场景五
尝试提升压力，观察 RT 情况：并发数 500，思考时间 400 ms
分析：
- CPU 使用率下降，可能是 c2 代码优化已经完成
- TPS 上涨，RT 没有明显变化，继续加压
场景六
并发数 500，思考时间 300 ms
分析
- cpu 没有到达瓶颈，继续加压
场景七
并发数 500，思考时间 200 ms
场景八
pubsub 调整内容：
- tomcat 线程数改为 200
- connection 连接池数量改为 200
分析：
CPU已打满，继续增加线程数无提升，线程数已接近理想状态值。
结论
CPU核数、Tomcat线程数、数据库连接池数比例约为：
1：100：100
将pubsub服务CPU核数修改为：8c，Tomcat线程数、数据库连接池数修改为：800
Consumer消费能力优化
初始状态：
- Consumer服务：2c-6g，启动一个消费者
- RocketMQ Topic读写队列总数均为48
- pubsub服务：8c-6g，单实例
- 消费者TPS：60左右
增加消费者
将消费者增加至20个：
消费服务资源使用情况：
定时消息回调接口：
消费者TPS：
可以看到增加消费者后，消费能力明显提升，但是个服务资源使用率都未达到上限。
继续增加Consumer数量，TPS并没有提升。
增加Topic Queue数量
Queue总数：96
（这里测试消费能力，可以只修改读队列数）
| 消费服务实例数 | 单个服务消费者数量 | 消费者总数 | 消费TPS |
|---|---|---|---|
| 1 | 20 | 3000左右 | |
| 1 | 40 | 40 | 3000左右 |
| 2 | 20 | 40 | 5000左右 |
| 2 | 40 | 80 | 5000左右 |
以上压测过程中，pubsub服务和消费者服务的资源使用率都只维持在中等水平，单个消费者实例上消费者数量达到40时，出现个别报错：
第一次出现这个异常，刚开始没仔细看异常信息，以为是pubsub回调接口处理不过来了，没有在意，造成了一个排查疏漏，走了一些弯路。
Queue总数：192
| 消费服务实例数 | 单个服务消费者数量 | 消费者总数 | 消费TPS |
|---|---|---|---|
| 1 | 20 | 20 | 3000左右 |
| 1 | 40 | 40 | 3000左右 |
| 2 | 20 | 40 | 5000左右 |
| 4 | 20 | 80 | 8500左右 |
| 5 | 20 | 100 | 9500左右 |
| 6 | 20 | 120 | 9500左右 |
Queue总数：900
| 消费服务实例数 | 单个服务消费者数量 | 消费者总数 | 消费TPS |
|---|---|---|---|
| 4 | 30 | 120 | 9000左右 |
| 5 | 30 | 150 | 12000左右 |
由于每一轮压测成本过高，已经达到预期，没有继续进行后续压测。
消费者在30*4时，再次出现大量异常：ConnectionPoolTimeoutException
初步结论：
-
增加消费者数量和 Topic队列数，可以有效提升消费者TPS
-
目前单个消费服务配置20~30个消费者达到消费峰值，但是消费服务和pubsub服务的资源使用还远远没到瓶颈。
-
消费服务内有http客户端，怀疑是瓶颈在http连接池上，而之前出现的异常：ConnectionPoolTimeoutException，正式由于http客户端使用了连接池，从连接池内获取http连接超时导致的。
调整消费程序http最大连接池数
消费程序中的http客户端使用的是apache提供的CloseableHttpClient，有两个线程池核心参数：
- maxTotal：连接池最大连接数
- defaultMaxPerRoute：每路由最大连接数
maxTotal默认是200，defaultMaxPerRoute默认是50，而消费程序中只会调用一个接口，所以实际只有50个连接是可用的，将defaultMaxPerRoute修改为200。
消费者TPS有提升，不再有报错信息，消费者服务CPU消耗有提升。
Consumer参数微调
对Consumer进行了几个参数的调试，包括：consumeThreadMax、consumeThreadMin、consumeMessageBatchMaxSize、pullBatchSize，其中consumeThreadMax、consumeThreadMin两个参数修改后对消费能力有较明显提升，其余两个对于顺序消费场景无明显提升。
consumeThreadMax、consumeThreadMin默认为20，修改为40：
CPU消耗有提升，加大consumeThreadMin后，消费者TPS可以瞬间达到消费峰值
继续加大consumeThreadMin后，消费TPS出现下滑。
Tips：Consumer客户端会根据消费线程的压力，动态增加消费线程：
总结
优化总结
- pubsub服务资源为8c-6g，核数和Tomcat线程数比例为1:100、Tomcat线程数和数据库连接池数比例为1:1；
- 基于以上配置，pubsub单实例定时消息接口QPS理想值为4500左右、回调接口QPS高于此；
- 目前Consumer最佳配置为单实例30个消费者，每个消费者配置consumeThreadMin=40，按理说可以通过增加资源，来增加单实例上的消费者数量，减少实例数，但是通过测试发现不可行，由于时间原因没有继续探索。
- 增加Topic 读队列数和消费者数量可以提升消费能力，本次测试过程中，消费者和队列数比例达到1:2时，获得最大消费TPS；
- pubsub程序初始时没设置xmn，导致young GC比较频繁，后续根据观察各区域内存的变化情况，将xmn设置为总堆大小的3/4。
经验总结
- 压测时间需要尽量长一点，需要等编译优化完成后，程序的性能才能达到一个稳定值，尤其是对刚启动的项目；
- 优化过程中要注意小细节，对任何出现的异常都需要精确定位后再继续，避免大方向错误；
- 借助Trace工具、prometheus指标暴露插件能更快定位问题；
- 若性能达到瓶颈时，资源使用率没有提升，需要考虑各环节中使用到的线程池、连接池的限制；
- 注意版本不同时，一些配置的变化，如：Tomcat线程数配置，spring 2.3版本之前：server.tomcat.max-threads，spring 2.3版本之后：server.tomcat.threads.max
- 做优化前，需要有一个整体的规划，对整体的性能瓶颈点有一个预先的认知，包括服务本身、使用到的各中间件配置、客户端配置等，逐个进行排除
6065
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
