>
> We've been able to get the crucial factors that cause this behavior down to
> a particular combination
What do you mean by this -- that you only see this when all four of those
operators
are at play? Or do you see it with any of them.
I guess the first thing to narrow down is whether it's
You might want to start with a lower commit interval, if you can handle some
additional latency. I would bet that the frequent flushing is a major part
of your
problem: not just the act of flushing itself, but the consequences for the
structure
of the data in each rocksdb. If you end up flushing
Hi all,
We have a Kafka Streams application which is showing high CPU usage. When
profiling the application we see that many of the hotspots are related to
RocksDB: flush, seek0, put iteratorCF and get methods.
We are using the default configuration for RocksDB. We read the documentation
but
Hi all,
We have a Kafka Streams job which has high CPU utilization. When profiling the
job, we saw that this was for a large part due to RocksDB methods: flush, seek,
put, get, iteratorCF. We use the default settings for our RocksDB state store.
Which configuration parameters are most
Does anyone have any idea what we can do?
All Zookeepers(3) and Kafkas are running. (5 nodes
meaning 5 physical hosts). Then I reboot one physical
host. I still have the redundancy. But when the physical host comes up and
zookeeper and then Kafka come up, I have Kafka timing out and not
Hi Pushkar,
No. You'd need to combine a consumer with a thread pool or similar as you
prefer. As the docs say (from
https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html
)
We have intentionally avoided implementing a particular threading model for
>
Hi,
Is there any configuration in kafka consumer to specify multiple threads
the way it is there in kafka streams?
Essentially, can we have a consumer with multiple threads where the threads
would divide partitions of topic among them?
