Redis hard
The `INFO memory` command reports a `mem_fragmentation_ratio` of 1.5. What is the specific technical interpretation of this metric?
- A Redis is using 50% more physical RAM (RSS) than the data itself actually requires due to page gaps or allocator overhead.
- B The total dataset size in bytes is exactly 1.5 times larger than the current maximum allocated heap partition limit.
- C All internal string values are being successfully compressed by a factor of 1.5x using the native LZ4 algorithm.
- D The memory health is optimal; this ratio indicates that the internal garbage collector is running at maximum efficiency.
Answer: A. Redis is using 50% more physical RAM (RSS) than the data itself actually requires due to page gaps or allocator overhead.
Fragmentation happens when keys are deleted/resized, leaving 'holes' in memory pages. The allocator (jemalloc) can't always give these back to the OS. If it gets too high, you can trigger 'Active Defragmentation' to shuffle data and close the holes.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- If the Redis memory limit is reached, what specific behavior is exhibited by the `allkeys-lru` eviction policy?
- What is the defining characteristic of a Redis 'Set' data type compared to a standard Redis 'List'?
- In the context of Redis messaging, what is the functional definition of the 'Pub/Sub' feature?
- How does the Redis background snapshotting process (`BGSAVE`) leverage the operating system's `fork()` mechanism to minimize memory overhead?
- Why does Redis proactively disconnect a Pub/Sub client that exhibits high 'output buffer' usage relative to its ingestion rate?
- How does a 'Sorted Set' (ZSET) manage its internal membership and ordering differently from a plain Set?