Kafka hard
Why is it strictly recommended to leave at least 50-70% of a Kafka Broker's system RAM free for the Operating System, even if the JVM Heap is small?
- A Because Kafka performs its own internal memory compression using the CPU's L3 cache.
- B To accommodate the Operating System's 'Page Cache', which buffers topic data from disk. Kafka's 'Zero-Copy' performance depends on these files staying in RAM to avoid actual physical disk reads.
- C To prevent the JVM from entering a 'Safepoint' pause during heavy metadata updates.
- D Because the Linux Kernel requires 32GB of RAM just to maintain the TCP stack for a Kafka cluster.
Answer: B. To accommodate the Operating System's 'Page Cache', which buffers topic data from disk. Kafka's 'Zero-Copy' performance depends on these files staying in RAM to avoid actual physical disk reads.
Kafka is 'Cache Blind'—it doesn't keep message data in the JVM Heap. Giving 32GB to the JVM on a 64GB machine actually *hurts* performance because it leaves less room for the OS to cache the partitions. A 6GB-10GB Heap is usually sufficient for most production Brokers.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- When implementing 'Exactly-Once Semantics' (EOS) in a Kafka stream, what is the role of the `isolation.level=read_committed` setting on the Consumer?
- Historically, which external service was required by Kafka to manage cluster hierarchy, metadata, and leader election status?
- Once a message is successfully appended to a Kafka partition log, what is its mutability status?
- In a Kafka cluster, what is the role of a 'Broker'?
- What is the primary indicator of a bottleneck in a Kafka consumer's processing logic?
- What is the primary architectural role of Apache Kafka in a distributed system?