这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@JerAguilon
Copy link

@JerAguilon JerAguilon commented Nov 14, 2025

Changelog category (leave one):

  • Performance Improvement

Changelog entry (a [user-readable short description]

Add kafka_consumer_reschedule_ms as a tunable Kafka table engine setting in order to adjust how long consumers sleep for new data.

Documentation entry for user-facing changes

  • Documentation is written (mandatory for new features)

This pull request is to address this issue that I reported: #89204

Essentially, if one were to set kafka_flush_interval_ms to be quite low (say, 250ms), one would expect that data would make its way to the downstream table in ~250ms. However, this is not the case, even if ingestion is happening very quickly. The reason is because there is a hardcoded 500ms stall that happens (a) when a consumer sees no messages or (b) when 1 minute passes.

This means that ingestion can happen much later than expected, as noted in my investigation. To fix, allow end users to tune this param while keeping the 500ms default.

@CLAassistant
Copy link

CLAassistant commented Nov 14, 2025

CLA assistant check
All committers have signed the CLA.

@JerAguilon JerAguilon changed the title Reschedule setting Make KAFKA_RESCHEDULE_MS a Kafka table setting Nov 15, 2025
@JerAguilon JerAguilon marked this pull request as ready for review November 15, 2025 01:35
@azat azat self-assigned this Nov 15, 2025
* Noticed that `StorageKafka2.cpp` wasn't calling the sanityCheck function on KafkaSetting
* Make tests cleaner
* I am running tests on an Ubuntu VM and tests were failing with this error described here:ClickHouse#15611. To fix, add additional filtering to not raise an error on this warning.
@JerAguilon
Copy link
Author

Ready for another review. TYSM for the prompt feedback @azat.

UInt64 ttl_usec = (*kafka_settings)[KafkaSetting::kafka_consumers_pool_ttl_ms] * 1'000;

std::unique_lock lock(mutex);
std::chrono::milliseconds timeout(KAFKA_RESCHEDULE_MS);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be explicit - this cleaning loop has nothing to do with consumer rescheduling as far as I can tell. So I am keeping this constant at 500ms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants