Hi： 你使用了 transientStorePoolEnable，这个模式的效果是先写内存(Buffer)，再写到PageCache，如果触发了Buffer没有及时归还，会导致写性能急剧下降。 建议改下配置压下： transientStorePoolEnable=false useReentrantLockWhenPutMessage=true sendMessageThreadPoolNums=32(核数乘以2)
压测时观察下broker.log里面的dispatch behind日志。 Best Regards dongeforever 在 2018年7月26日 下午5:45，shen hui <shenhui0...@outlook.com>写道： > 我理解既然最开始的写入TPS能够到达4000左右，并且能够持续一段时间，那么集群的容量就是4000TPS。但是每次new 一个mapped > file的时候，TPS就下来了，十分疑惑。 > ps：os是 Debian 3.16.56-1+deb8u1， kernel版本是 3.16.0-6-amd64， > 文件系统是ext4。 > ------------------------------ > *发件人:* 骆志杰 <aluomaidi...@163.com> > *发送时间:* 2018年7月26日 17:27 > *收件人:* users@rocketmq.apache.org > *主题:* Re: 求助：broker的message store在AllocateMappedFile之后写入TPS急剧下降 > > 1.其实属于一种服务端保护机制，压测的场景下很容易出现，解决方案有两种，一个是增强写入能力，另一个是放宽安全限制。 > 2.增强写入能力：可以增加master分摊流量或者调整可以增加broker写入的参数 > 3.放宽限制：设大osPageCacheBusyTimeOutMills，waitTimeMillsInSendQueue， > sendThreadPoolQueueCapacity等参数 > 4.我自己测试过调整3中的参数以后没有再出现这个异常 > > 在 2018年7月26日，17:00，张凯 <zhangkai....@gmail.com> 写道： > > 网络有问题么 > > shen hui <shenhui0...@outlook.com> 于2018年7月26日周四 下午3:15写道： > > 更新一下，AllocateMappedFile应该不是诱因，上面的store.log是巧合。 > > 而且这次的put的延时有很多 <= 0ms。看了下磁盘io和内存的cached的使用，远没有到瓶颈。可能的原因是什么呢？ > ------------------------------ > *发件人:* shen hui <shenhui0...@outlook.com> > *发送时间:* 2018年7月26日 12:12 > *收件人:* users@rocketmq.apache.org > *主题:* 求助：broker的message store在AllocateMappedFile之后写入TPS急剧下降 > > HI， > 在测试RocketMQ-4.2.0的时候，使用benchmark下的producer.sh进行写入性能测试，同时也开启了consumer进行消费。 > > broker的机器配置为（从kafka集群借过来的） > > CPU ： E5-2650 v4 @ 2.20GHz > Mem：256G > disk ： 7200 rpm HDD 12T > > 集群为3 master - 6 slave，异步刷盘、同步复制。9个实例分布在3台物理机上，每个物理机上一个master实例。 > master 的参数如下: > brokerClusterName=test_cluster > brokerName=broker1 > brokerId=0 > deleteWhen=04 > fileReservedTime=48 > brokerRole=SYNC_MASTER > flushDiskType=ASYNC_FLUSH > namesrvAddr=10.21.62.12:9876;10.21.62.13:9876 > transientStorePoolEnable=true > listenPort=10911 > storePathRootDir=/data01/rocketmq_data > storePathCommitLog=/data01/rocketmq_data/commitlog > autoCreateTopicEnable=false > autoCreateSubscriptionGroup=false > slaveReadEnable=true > > 刚刚开始的时候，producer的TPS在 3500 ～ 4500，但是一段时间过后，TPS急剧下降两位数水平。客户端日志开始大量出现 > [TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a while, period > in queue: 202ms > 的错误。通过mqadmin增大broker的waitTimeMillisInSendQueue到500ms也未见好转 > > 同时观察master broker的store.log，发现是在allocate mapped file之后开始下降的。 > slave的日志没有发现warn或者error > > 而且，重启broker之后，写入TPS恢复，但是一段时间后又出现了这种问题。 > 请问下各位，是我参数配置错误还是说一台机器上多个实例造成的影响？我看了半天源码也没想明白原因。望指教 > > <image.png><image.png><image.png><image.png> > > >
