How do you troubleshoot a slow Kafka consumer?

Official answer

Start by locating the delay: fetch, application processing, downstream I/O, commit, or repeated rebalances. Compare per-partition lag and arrival rates with completed-work rates. Distinguish the consumer's fetched position from its committed offset and from work still queued inside the application.

Profile processing time, database/API latency, retries, CPU, allocation/GC and queue depth. Check broker request timing, network errors, throttling and disk pressure. A hot partition or slow dependency requires a different remedy from uniformly overloaded consumers.

Review fetch.min.bytes and fetch.max.wait.ms as throughput/latency tradeoffs. max.poll.records limits records returned by a poll, not the underlying fetch size. Keep processing and polling behavior compatible with max.poll.interval.ms; repeatedly increasing the timeout can hide a stuck processor rather than fix it.

For the Java KafkaConsumer, do not share the consumer instance freely across worker threads: it is not thread-safe. If processing is delegated, set enable.auto.commit=false, keep consumer operations on its owner thread, bound the queue and preserve required per-partition order. Manually commit only the next offset after the contiguous successfully completed prefix of delivered records; offset numbers need not be consecutive. Automatic commits can otherwise advance past unfinished work while the owner continues polling. Handle revocation and shutdown so outstanding work cannot silently commit after ownership changes. Pause/resume can help control intake while maintaining the consumer's required polling behavior.

Scale conventional group members only where partitions and downstream capacity permit. Change one measured bottleneck at a time, then verify throughput, tail latency and replay/duplicate behavior under failure. A faster poll loop is not proof that business processing completes faster.

Sources

KafkaConsumer threading and processing guidance; consumer configuration.