Caching hard
During a Redis BGSAVE (Snapshot), memory usage can potentially double. Why?
- A The primary Redis process must load a second, independent copy of the entire dataset into RAM before it can safely initiate a background snapshot.
- B The OS 'Copy-on-Write' mechanism duplicates memory pages modified by the parent process while a child process is dumping the dataset to the disk.
- C The fork() system call utilized by the Redis server immediately duplicates all physical memory addresses to ensure the child process has a stable state.
- D Redis must allocate an entirely new, secondary hash table to accommodate all incoming write operations while the primary table is being dumped.
Answer: B. The OS 'Copy-on-Write' mechanism duplicates memory pages modified by the parent process while a child process is dumping the dataset to the disk.
The redis `BGSAVE` command forks the process to create a snapshot. The OS uses **Copy-on-Write (CoW)** to efficiently share memory between parent and child. However, if the parent process continues to receive heavy write traffic, it must duplicate memory pages to preserve the snapshot's state. In the worst case (100% of keys modified during save), memory usage doubles.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In the Cache-Aside pattern, what happens when the application requests data that is missing from the cache (a 'Cache Miss')?
- Why use a centralized Distributed Cache (like a Redis Cluster) over local in-memory caches on each web server?
- Setting a short TTL (e.g., 60 seconds) on a cached object helps to:
- What is the primary architectural goal of introducing a cache into a system?
- Most caching systems rely on the principle of 'Temporal Locality', which states:
- Your cache uses an LRU (Least Recently Used) eviction policy. When the cache is full, which item is removed?