masterOcean

> 你的问题跟这两个指标关系不大。大消息体在rpc过程中对cpu的消耗不能忽视，目前为减少内存copy，mqtt payload会在direct memory上分配，并且再完成dist后才会被间接释放。用OpenJDK的话，可以尝试通过JVM Arg `-XX:ZCollectionInterval=N`提升gc的频率来加速间接回收。另外，你的生产环境只有2C 4G？你期望的性能目标是什么？ 1. 我们其实关注的是理论上 qos 0 消息不会持久化的，为什么 dist 模块设置的 dataEninge 设置为 rocksdb 时比 memory 差这么多； 2. 我们是在测试环境验证时发现了这个问题，生产环境肯定不是这个配置了

> cleansession=true，消息并没有持久化，你说的性能差指哪方面，吞吐，latency？有数字吗？还是仅是rocksdb下，direct memory OOM了？ rocksdb 下, direct memory OOM 了，然后吞吐 比 dataEngineType = memory 差很多

> 很远是多少，用的什么压测工具，提供下详细的压测参数？如果是OOM了，吞吐必然受影响，你最好先优化下gc参数，保证不OOM的情况下，在对比结果 1. 压测工具是测试同学 golang 开发的。测试参数： 4w cleanSession=true 的连接，客户端每隔 2S 发送 4K 的消息（所有客户端不是一起发送的，没有峰值压力），发送topic 为 xxx/${client_id}/pub，没有客户端订阅这些消息。 2. memory 性能大概是 rocksdb 的 4倍（memory 能支持 16k 消息， rocksdb 下只有 3.8k ） 3. gc...

> > 检查下你rocksdb和memory运行的gc日志里gc运行的频率差异。 > > 3个`2C 4G`Node Cluster下用emqtt_bench测rocksdb + 16KB payload并没有出现你说的问题，Direct Buffer稳定在800MB左右 cmd: `./emqtt_bench pub -V 4 -h -c 40000 -I 2000 -i 1 -t bench/%i -s 16384 -u DevOnly/16KPayload`...