You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@rocketmq.apache.org by 智齿 <ja...@foxmail.com> on 2018/02/11 04:13:16 UTC
回复: need help on RocketMQ data flow Map (with a question :)
Hi ,
Yukon shared us a data flow map with a question.
I have tried all my power reading the map without getting a specfic answer.
Does anyone have idea with making it a new interesting incubator version!
Really appreciate your "bit Data" source for helping on feeding it up!
Sorry for any rude actions/impolite words bothered you.
Many thanks in advance!
Sincerely
Regards
------------------ 原始邮件 ------------------
发件人: "xuzhenzhenyf"<xu...@foxmail.com>;
发送时间: 2018年2月10日(星期六) 中午1:09
收件人: "users"<us...@rocketmq.apache.org>;
主题: Re: RocketMQ 3.5.8流控问题
Hi guys,
I met a flow control problem. Here is config:
Version: rocketmq 3.5.8
Broker: 3m-3s-async
flushDiskType:ASYNC_FLUSH
Jvm:-Xms 4g -Xmx 4g -xmn 2g -XX:PermSize=128m -XX:MaxPermSize=320m -XX:ParallelGCThreads=2 -XX:ConcGCThreads=1
Env: Docker, no cpu limit, 16G memory,(The host has 40 cpus and deploys about 20-30 docker instances(not mq), all instances is no cpu limit)
sendMessageThreadPoolNums=28
pullMessageThreadPoolNums=22
When the tps is only 100-200, some master start flow control.Most of logs in producer is like this:
[TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a while, period in queue: 201ms, size of queue: 35
Some logs is:
[REJECTREQUEST]system busy, start flow control for a while
[PCBUSY_CLEAN_QUEUE]broker busy, start flow control for a while, period in queue: 3ms, size of queue: 66
There are warning logs in master sometimes, like:
[NOTIFYME]putMessage in lock cost time(ms)=1557, bodyLength=108 AppendMessageResult=AppendMessageResult{status=PUT_OK,...pagecacheRT=1557}
putMessage not in lock eclipse time(ms)=1557, bodyLength=110
Sometimes pagecacheRT=0.
Sometimes only has "not in lock time” log:
putMessage not in lock eclipse time(ms)=1440, bodyLength=108
The flow control happens in one broker mostly,and the others is fine.
The gc time is about 100ms,it mostly doesn’t happen is gc period
In another cluster, 1m-1s-async with mq config, its tsp can reach 10000 until happening flow control
Does anyone have idea about this problem,where is bottleneck probably,memory,disk, or cpu?
Just in English
On 2018/02/09 05:56:29, "752832634" <x....@foxmail.com> wrote:
> Hi guys>
>
>
>
>We met a trouble, is there any help on this!