ing this method, but
> it resulted in no consumer down time which was all that mattered :)
>
>
>
> On Wed, Jan 17, 2018 at 10:07 AM, Shravan R wrote:
>
> > BTW, I see log segments as old as last year and offsets.retention.minutes
> > is set to 4 days. Any reason why it
104857564 Apr 7 2017 12192643.log
-rw-r--r-- 1 kafka kafka 104857578 Apr 7 2017 13411917.log
On Tue, Jan 16, 2018 at 1:04 PM, Shravan R wrote:
> I looked into it. I played with log.cleaner.dedupe.buffer.size between
> 256MB to 2GB while keeping log.cleaner.threads
concern at this time. Is there any work around or tuning that I can do?
Thanks,
SK
On Tue, Jan 16, 2018 at 10:56 AM, naresh Goud
wrote:
> Can you check if jira KAFKA-3894 helps?
>
>
> Thank you,
> Naresh
>
> On Tue, Jan 16, 2018 at 10:28 AM Shravan R wrote:
>
> >
We are running Kafka-0.9 and I am seeing large __consumer_offsets on some
of the partitions of the order of 100GB or more. I see some of the log and
index files are more than a year old. I see the following properties that
are of interest.
offsets.retention.minutes=5769 (4 Days)
log.cleaner.dedup
