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

在 2018年4月8日 上午10:07,Zhanhui Li <lizhan...@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 <iamzhou...@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的区别在什么地方呢?
>>
>
>

Reply via email to