Overhead is the allocated size of the AOF buffer, not its length#5453
Overhead is the allocated size of the AOF buffer, not its length#5453antirez merged 1 commit intoredis:unstablefrom
Conversation
|
This looks correct to me @damz and indeed may be source of issues. Btw in your investigation, you actually found the following?
I don't understand 4, what was the maxmemory policy? Anyway the fix is needed, but technically with an evicting memory policy we should just see a mass-eviction of keys because of this bug, and not an error reported to the client. CCing @oranagra @soloestoy FYI. |
|
For point 2
As I know there are two scenarios can lead to that:
|
@antirez In this case, the policy was |
Actually we see both: the eviction keys counter is pretty high (tens thousands) and time to time we're getting the "OOM command not allowed" error. |
|
@soloestoy merged your PR. Also merging @damz PR. Thanks both. |
Overhead is the allocated size of the AOF buffer, not its length
4 participants
freeMemoryGetNotCountedMemory()usessdslen(server.aof_buf)when trying to remove memory that is not used as part of the main database, where it should usesdsallocinstead. This causes AOF to induce eviction although it is unecessary, and could end up resulting in OOM errors being returned to the client if there is not enough evictable keys available.We were trying to debug why Redis was returning a OOM error on a write spike on a old 3.2.11 server with AOF enabled, and code review led us to this. We haven't confirmed that it solves the problem. I'm uploading this for discussion.