Elasticsearch hard
Elasticsearch best practices suggest keeping the JVM Heap size slightly below 32GB (e.g., 30-31GB). What specific Java performance optimization is sacrificed if this threshold is crossed?
- A The JVM loses the ability to perform 'Thread-Local Allocation Buffers' (TLABs), increasing lock contention.
- B Compressed Ordinary Object Pointers (Compressed Oops): The JVM shifts from 32-bit to 64-bit memory addresses, potentially consuming significantly more RAM for the same object count and reducing effective cache utility.
- C The Garbage Collector (G1GC) loses the ability to perform 'Humongous Object' allocations in a single cycle.
- D The JIT compiler can no longer use SIMD (Single Instruction, Multiple Data) instructions for Lucene math.
Answer: B. Compressed Ordinary Object Pointers (Compressed Oops): The JVM shifts from 32-bit to 64-bit memory addresses, potentially consuming significantly more RAM for the same object count and reducing effective cache utility.
Below ~32GB, Java can use 4-byte offsets to reference objects. Above that, it must use full 8-byte pointers. This effectively means that a 31GB heap often has more 'usable' space for data than a 36GB heap, as the 36GB heap is bloated by the larger pointers. This is a critical ceiling for Elasticsearch architects.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What are the two primary reasons for configuring one or more 'Replica Shards' for an index?
- When a String field is mapped as `text`, what process is performed to enable full-text search capability?
- What is the primary benefit of splitting an Elasticsearch index into multiple 'Primary Shards'?
- Every document stored in an Elasticsearch index is uniquely tracked by which mandatory metadata field?
- Elasticsearch search results include a metadata field called `_score`. What does this value primarily indicate?
- What is the primary architectural purpose of Elasticsearch in a modern software stack?