Thanks for reporting the results. Maybe you could submit a PR that updates
the ops section?
https://github.com/apache/kafka/blob/trunk/docs/ops.html
Ismael
On Fri, Jul 21, 2017 at 2:49 PM, Ovidiu-Cristian MARCU <
ovidiu-cristian.ma...@inria.fr> wrote:
> After some tuning, I got better results.
After some tuning, I got better results. What I changed, as suggested:
dirty_ratio = 10 (previously 20)
dirty_background_ratio=3 (previously 10)
It results that disk read I/O is almost completely 0 (I have enough cache, the
consumer is keeping with the producer).
- producer throughput remains
Hi Ovidu,
The see-saw behavior is inevitable with linux when you have concurrent
reads and writes. However, tuning the following two settings may help
achieve more stable performance (from Jay's link):
> *dirty_ratio*Defines a percentage value. Writeout of dirty data begins
> (via *pdflush*) whe
Yes, I’m using Debian Jessie 2.6 installed on this hardware [1].
It is also my understanding that Kafka is based on system’s cache (Linux in
this case) which is based on Clock-Pro for page replacement policy, doing
complex things for general workloads. I will check the tuning parameters, but I
I suspect this is on Linux right?
The way Linux works is it uses a percent of memory to buffer new writes, at
a certain point it thinks it has too much buffered data and it gives high
priority to writing that out. The good news about this is that the writes
are very linear, well layed out, and hig
