How much memory should we use for broker and namesrv when using cluster mode?

[hepyu]

First, 3Q for your work, after research, we decided to use rocketmq, but we met some problem when deploying rocketmq cluster.

RT：
How much memory should we use for broker and namesrv when using cluster mode?

I noticed the default memory is set up to 4G of namesrv, 8G of broker.
And direct memory is set up to 15G like this:
MaxDirectMemorySize=15g

Is that mean I should use 30G for every namesrv, broker? that looks unreasonable.

And, is some advice about memory? 3Q so much.

[Cicizz]

Hello,the machine configuration needs to depend on your messages.
there is some configuration we are using now:
CPU:8C
Memory:16G
DISK:1T
ASYNC_FLUSH and SYNC_MASTER is adviced.
and you can extend the server to meet your needs.

[hepyu]

Hello,the machine configuration needs to depend on your messages.
there is some configuration we are using now:
CPU:8C

Memory:16G
How much should we set about the jvm param MaxDirectMemorySize? default value is 15G.

DISK:1T
ASYNC_FLUSH and SYNC_MASTER is adviced.
and you can extend the server to meet your needs.

I think this is the config and machine-resource for the broker node. How about advices about config and machine-resource for namesrv machine?

[hepyu]

Hello,the machine configuration needs to depend on your messages.
there is some configuration we are using now:
CPU:8C
Memory:16G
DISK:1T
ASYNC_FLUSH and SYNC_MASTER is adviced.
and you can extend the server to meet your needs.

I still have some questions, 3Q~

1.And how about the benchmark when using these resource and config?
2.Is disk ssd?

This is our play, is this ok?

[hepyu]

And we plan to use multi master, no slave.
So we will keep the broker_role as default value:ASYNC_MASTER.
Of course, ASYNC_FLUSH will be used.

[Cicizz]

namesrv manage broker info and topic info and store all info in the memory,so i think 16g mem is more
suitable,but if your topic and queue are relatively few,8g is OK。for 3 broker, i think 2 namesrv is OK.
and only master may lost messages.
so 2M - 2S is adviced。
There are some configuration we are using now
2 namesrv: 8cpu and 16g
4 cluster,per cluster have 2 master and 2slave.
broker : 2M-2S.
3E messages a day.

[hepyu]

3Q so much~~

[hepyu]

namesrv manage broker info and topic info and store all info in the memory,so i think 16g mem is more
suitable,but if your topic and queue are relatively few,8g is OK。for 3 broker, i think 2 namesrv is OK.
and only master may lost messages.
so 2M - 2S is adviced。
There are some configuration we are using now
2 namesrv: 8cpu and 16g
4 cluster,per cluster have 2 master and 2slave.
broker : 2M-2S.
3E messages a day.

3Q for your answer, but I still have some confused.

1.the namesrv just save broker and topic info, I think they cost memory little, is 16G is too large? I think even 8G is also too large, is this right?

2.About lost message when only using master, is this happen only when master disk is wrong? I mean if we don't consider the disk broken, the rocketmq won't lose message, is this right?

3.If we use slave feature, is it will have some influences about the qps? And How big is the impact?

4.And what about the qps when using the config as you advice?

[Cicizz]

@hepyu
1.the namesrv just save broker and topic info, I think they cost memory little, is 16G is too large? I think even 8G is also too large, is this right?
it depends on your topics, 8g is OK.but 2 namesrv is enough.

2.About lost message when only using master, is this happen only when master disk is wrong? I mean if we don't consider the disk broken, the rocketmq won't lose message, is this right?
if you use async_flush,when broker crash and message hasn't flush to the disk,then the message lost.
3.If we use slave feature, is it will have some influences about the qps? And How big is the impact?
yes ,but it can gurantee the message reliability
4.And what about the qps when using the config as you advice?
1.pub message: message size:2K and tps is 40000
2.consume message:messages size 2k and tps is 60000.
message size affects TPS.

[hepyu]

@hepyu
1.the namesrv just save broker and topic info, I think they cost memory little, is 16G is too large? I think even 8G is also too large, is this right?
it depends on your topics, 8g is OK.but 2 namesrv is enough.

How could I understand "it depends on your topics", is this mean if topics/queues/brokers are too many, the infos will cost much more memory? But will they cost 8g?

In other words, I mean , 8g memory of namesrv could hold how many topics/queues/brokers?

Just to control the money if biz accept...

2.About lost message when only using master, is this happen only when master disk is wrong? I mean if we don't consider the disk broken, the rocketmq won't lose message, is this right?
if you use async_flush,when broker crash and message hasn't flush to the disk,then the message lost.

yeah, it is, but I think the broker would run stablely at most of the time, if it is and we could accept the little crase case about broker, is this make some sence?
And how about the broker crase rate? Is there some common crash reason? for example, too busy io, too high load, tec.

And What about the disk type? namesrv and broker are all ssd?

3.If we use slave feature, is it will have some influences about the qps? And How big is the impact?
yes ,but it can gurantee the message reliability

Yes, I agree. Just to control the money if biz accept...

4.And what about the qps when using the config as you advice?
1.pub message: message size:2K and tps is 40000
2.consume message:messages size 2k and tps is 60000.
message size affects TPS.

Is this tps running under these resources as you adviced before?
4 cluster,per cluster have 2 master and 2slave.
broker : 2M-2S.
namesrv-machine: 8cpu and 8g
broker-machine: 8cpu and 16g

[Cicizz]

@hepyu
SSD will improve broker performance significantly and we use HDD in production。
1.rocketmq support 10W+ topics,8g is enough in pre-application.
2.you must run benchmark to test it.'

[Force-King]

The key is to tune the JVM. A timeout occurs when the GC STW affects the execution of the thread
if you use G1, Never configure Xmn and -XX:NewRatio