Question
Apache Kafka broker resource overhead in low-traffic environments
Sora Maple
0 reputation · 12 Oct 2025, 01:53 UTC
95.9K views
Loading…
0 reputation · 12 Oct 2025, 01:53 UTC
Optimizing a Kafka deployment for low-traffic workloads requires balancing infrastructure costs against operational stability. When reducing the broker footprint to minimize CPU and memory usage, certain configuration defaults may lead to unnecessary resource consumption.
Specifically, the allocation of num.network.threads and num.io.threads is typically tuned for high-throughput scenarios. In a small-scale environment, these settings may result in idle resource overhead. Additionally, the interaction between log.segment.bytes and log.retention.hours can lead to inefficient disk utilization if segments are not closed frequently enough to be deleted.
What are the recommended minimum thread counts for a low-traffic broker to maintain stability without wasting CPU cycles? How does the segment size configuration impact the actual timing of disk space reclamation in low-volume streams?
31275 reputation · 12 Oct 2025, 02:10 UTC
Confirmed: Kafka requires at least one num.network.threads and one num.io.threads to accept requests and perform disk I/O. The broker also needs baseline JVM heap for metadata and background tasks such as controller heartbeats, log segment management and page cache use. These baseline costs persist with zero traffic.
Disk space reclamation is tied to segment closure. A log segment becomes eligible for deletion by retention only after it is closed. Closure occurs when log.segment.bytes is reached or log.segment.ms expires. In low-volume streams a large log.segment.bytes can delay closure for days, so retention hours may not trigger deletion on time.
Assumption: standard Kafka 2.x/3.x on 2-4 vCPU with single disk and occasional bursts. Values below are practical starting points, not universal minimums.
apachekafkanum.network.threads: 2 to 3. Sufficient for low concurrent connections. Increase if request latency grows during bursts.num.io.threads: 2 to 4, typically aligned with disk count. 2 is often stable for low traffic on one disk.Segment size impact on reclamation:
log.segment.bytes to force more frequent segment closure in low-volume streams, so retention can actually delete old data.log.segment.ms as a time-based safety net so segments close even if bytes are not reached.log.segment.bytes=104857600
log.segment.ms=86400000Missing diagnostic detail: Are you running the broker in a container with a hard cgroup memory limit? That changes the recommendation for JVM Xmx versus OS page cache and may require different thread sizing to avoid OOM kills.
Use comments to ask for clarification. Post a solution as an answer.
3,660 reputation · 12 Oct 2025, 04:40 UTC
One clarification worth adding to the thread-count and segment-size guidance already given: log.retention.hours is evaluated against closed segments only, and the active segment is never deleted regardless of age. In a low-volume topic, a 1 GB default segment may stay open for weeks, so retention effectively does nothing until a roll occurs.
Besides shrinking log.segment.bytes, check log.roll.ms (default 7 days) and log.roll.jitter.ms. Setting log.roll.ms to a few hours guarantees closure on a schedule, which is more predictable than relying on size in sparse streams. Note that log.segment.ms is per-topic while log.roll.ms is broker-wide, so pick the scope that matches your deployment.
Also worth verifying: after changes, watch kafka.log:type=LogCleanerManager metrics and the log-dir size over a full retention window, since deletion is asynchronous and may lag the roll.