[ROCKETMQ-31] Fix "No such file or directory" warning for $HOME/rmq_b…

[iskl]

The PR is to resolve the issue ROCKETMQ-31

[shroman]

I would fix -Xloggc:/dev/shm/mq_gc_%p.log to point to $HOME or better everything to /var/log/rocketmq instead of removing these two lines ;)

[iskl]

Dear @shroman , thanks for your suggestion :)

In my concept, broker thread is time sensitive. When broker thread in a MQ broker is in I/O operation and GC occurs, an I/O competition appears between broker thread and GC thread. It may bring long time latency to broker thread.

Linux distributions based on the 2.6 kernel and later offer /dev/shm as shared memory in the form of a RAM disk (link). Pointing GC log to /dev/shm can avoid I/O competition between broker thread and GC thread.

In conclusion, I tend to use -Xloggc:/dev/shm/mq_gc_%p.log :)

[shroman]

yes, I see, you want to reduce disk I/O by placing the file into /dev/shm.

Well, GC logging has a minimal overhead. And to get a high-performance broker, I would tune my JVM to get smaller GC pauses, which has much larger impact on the overall performance.

Also, is it ok not to persist your GC logs? Long-term logging is essential for analysis of the brokers' performance.

[zhouxinyu]

It's our mistake. As @iskl says, we print gc logs to tmpfs in order to eliminate long time latency brought by disk I/O competition.

IMO, we can merge this PR at current state, and open another issue to discuss where to place GC logs. How about your advise? @shroman -:)

[shroman]

@zhouxinyu @iskl's concerns are valid indeed.
My major concern is the logs can be lost when the system crashes. I think it's a good idea to discuss it in another JIRA issue.
I will create a JIRA issue, if it's ok with you.

[zhouxinyu]

@shroman it's ok surely.
Please @lizhanhui @stevenschew help review this pr.

[stevenschew]

it's good idea, review ok

[shroman]

@zhouxinyu @stevenschew Thanks, guys, https://issues.apache.org/jira/browse/ROCKETMQ-36 is created to consider the improvement.