1.其实属于一种服务端保护机制，压测的场景下很容易出现，解决方案有两种，一个是增强写入能力，另一个是放宽安全限制。 2.增强写入能力：可以增加master分摊流量或者调整可以增加broker写入的参数 3.放宽限制：设大osPageCacheBusyTimeOutMills，waitTimeMillsInSendQueue，sendThreadPoolQueueCapacity等参数 4.我自己测试过调整3中的参数以后没有再出现这个异常
> 在 2018年7月26日，17:00，张凯 <[email protected]> 写道： > > 网络有问题么 > > shen hui <[email protected] <mailto:[email protected]>> > 于2018年7月26日周四 下午3:15写道： > 更新一下，AllocateMappedFile应该不是诱因，上面的store.log是巧合。 > > 而且这次的put的延时有很多 <= 0ms。看了下磁盘io和内存的cached的使用，远没有到瓶颈。可能的原因是什么呢？ > 发件人: shen hui <[email protected] <mailto:[email protected]>> > 发送时间: 2018年7月26日 12:12 > 收件人: [email protected] <mailto:[email protected]> > 主题: 求助：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 <http://10.21.62.12:9876/>;10.21.62.13:9876 > <http://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>
