rocketmq 写消息的时候，为什么先把消息写到一个bytebuffer里面，然后再刷到磁盘上？

[yuzhou li <ia...@gmail.com>]

/**
 * Message will put to here first, and then reput to FileChannel if
writeBuffer is not null.
 */
protected ByteBuffer writeBuffer = null;


看MappedFile里面，有一个这样的buffer，然后查看他的用途，是消息先写到这个里面了，而每次rocketmq出现流控的时候，就是写这个buffer耗时很大的时候。。
所以我想问题这么设计的初衷是什么呢？直接用channel刷pageCache的话，和先写buffer，再刷channel的区别在什么地方呢？

Re: rocketmq 写消息的时候，为什么先把消息写到一个bytebuffer里面，然后再刷到磁盘上？

[yuzhou li <ia...@gmail.com>]

谢谢Zhanhui，我这边很疑惑的一个点为什么我写一条128字节的消息，只是往writeBuffer里面写，有时会达到500ms的时延(一分钟到两分钟不等就会出现一次)，看CPU负载，非常低，也没有IOwait，由于是异步刷盘，而且根据你刚才说的，写writeBuffer也不需要担心有操作系统回收内存导致的延时；jvm
gc也比较少，最多30ms。请问我还可以从哪些方面去分析这个问题呢？因为每次有延迟很高的写入的时候，就会触发一波流控，导致可用性下降，尽管这个流控的阈值可调，但是还是想研究一下问什么会出现写bytebuffer花费500ms以上时延的这种情况。。

在 2018年4月8日 上午10:07，Zhanhui Li <li...@apache.org>写道：

> writeBuffer 是预分配的anonymous pages, 并且mlock到物理内存了. 往里面写消息, 不会因为内存不足回收带来延迟.
> mmap的文件page cache, 在物理内存分配过快, background reclaim速度跟不上的时候, 线程会被block住,
> 进行direct reclaim, 带来延迟.
>
> 可参考:  https://events.static.linuxfound.org/sites/events/
> files/lcjp13_moriya.pdf
>
> 祝好
>
>
> 2018-04-07 13:50 GMT+08:00 yuzhou li <ia...@gmail.com>:
>
>> /**
>>  * Message will put to here first, and then reput to FileChannel if writeBuffer is not null.
>>  */
>> protected ByteBuffer writeBuffer = null;
>>
>>
>> 看MappedFile里面，有一个这样的buffer，然后查看他的用途，是消息先写到这个里面了，而每次rocketmq出现流控的时候，就是写这个buffer耗时很大的时候。。
>> 所以我想问题这么设计的初衷是什么呢？直接用channel刷pageCache的话，和先写buffer，再刷channel的区别在什么地方呢？
>>
>
>

Re: rocketmq 写消息的时候，为什么先把消息写到一个bytebuffer里面，然后再刷到磁盘上？

[Zhanhui Li <li...@apache.org>]

writeBuffer 是预分配的anonymous pages, 并且mlock到物理内存了. 往里面写消息, 不会因为内存不足回收带来延迟.
mmap的文件page cache, 在物理内存分配过快, background reclaim速度跟不上的时候, 线程会被block住,
进行direct reclaim, 带来延迟.

可参考:
https://events.static.linuxfound.org/sites/events/files/lcjp13_moriya.pdf

祝好


2018-04-07 13:50 GMT+08:00 yuzhou li <ia...@gmail.com>:

> /**
>  * Message will put to here first, and then reput to FileChannel if writeBuffer is not null.
>  */
> protected ByteBuffer writeBuffer = null;
>
>
> 看MappedFile里面，有一个这样的buffer，然后查看他的用途，是消息先写到这个里面了，而每次rocketmq出现流控的时候，就是写这个buffer耗时很大的时候。。
> 所以我想问题这么设计的初衷是什么呢？直接用channel刷pageCache的话，和先写buffer，再刷channel的区别在什么地方呢？
>