How does maxmemory policy work when using MemoryDB with Data Tiering

Hello,

I understand that you would like to know about how does maxmemory policy work when using MemoryDB with Data Tiering.

As mentioned in the AWS document , MemoryDB monitors the last access time of every item it stores. When available memory (DRAM) is fully consumed, MemoryDB uses a least-recently used (LRU) algorithm to automatically move infrequently accessed items from memory to SSD. When data on SSD is subsequently accessed, MemoryDB automatically and asynchronously moves it back to memory before processing the request.

Note that when using data tiering, keys themselves always remain in memory, while the LRU governs the placement of values on memory vs. disk. In general, we recommend that your key sizes are smaller than your value sizes when using data tiering. Value size cannot be greater than 128MB; else it will not be moved to disk. When items are moved between DRAM and SSD, keys will always remain in memory and only the values are moved to the SSD tier.

Please allow me to clarify that, when we say eviction it means the number of keys that have been evicted due to the maxmemory limit which is derived from the evicted_keys statistic at Redis INFO.

So, what happens during this eviction period is that when a client runs a new command, resulting in more data added. Redis checks the memory usage, and if it is greater than the maxmemory limit , it evicts keys according to the policy. A new command is executed, and so forth. In your case, as you mentioned, you are using allkeys-lru, in this what ideally should be happening is Redis will keeps most recently used keys but removes least recently used (LRU) keys. It would be difficult to tell what exactly happened without much insights on to the cluster, but it's possible that the evictions didn't occur due to certain conditions not being met. For example, if the keys being accessed were frequently requested, they might remain in memory despite the eviction policy.

You could also monitor the memory usage and eviction activity using the CloudWatch metrics to see if there are any patterns or anomalies.

That being said, I would request you to review the AWS knowledge document which discusses about to resolve this error and to prevent clients from receiving OOM command not allowed error messages.

If the problem persists, I would recommend reaching out to the AWS Support MemoryDB team for consulting the specific troubleshooting steps could be helpful in getting more insights and resolving the issue.

I hope the above guidance helps you in your cloud journey.