When you said "The only difference we could see is that thread usage
decreases during these period", did you mean thread usage increases?
You can monitor the usage of two different thread pools, network
thread pool and requestHandler thread pool. If none of them are high
and yet, you have a large C
Point 2 may impact if the size of partitions is too big.
too many log segments will cause those many iops
I am not expert though
On Wed, 9 Aug 2023 at 6:43 PM, Tiansu Yu
wrote:
> 1. We use cruise-control to actively balance the partitions across all
> brokers. So point 1 could be ruled out.
> 2.
The Kafka version is 3.2. Replication factor is defined per topic, but minimum
3. We have no control over every producer, but we do recommend our users to set
acks as all.
Another angle we are considering is that there might be some misbehaving
clients using Kafka low level APIs that might not
Which kafka version are you running? Which replication factor is being
used? are producers using acks=all?
On Wed, Aug 9, 2023 at 9:14 AM Tiansu Yu
wrote:
> 1. We use cruise-control to actively balance the partitions across all
> brokers. So point 1 could be ruled out.
> 2. I am not sure how muc
1. We use cruise-control to actively balance the partitions across all brokers.
So point 1 could be ruled out.
2. I am not sure how much this would impact the broker, as we do have some
exceptionally large partitions around. I have to check to know if they live on
the aforementioned broker. So
Hi I can guess two problems here.
1. Either too many partition’s concentrated on this broker compared to
other broker
2. The partitions on this broker might have larger size as compared to the
parition on other brokers
please chech if all brokers are evenly balanced in terms of number of
partition
