The read performance of Redis cluster (version > 2.8.22 in AWS) we have is being affected lately by regular scheduled snapshots/backups. I see read operations increase in latency (or Timeouts) at the time of creation of redis backups.
As per AWS docs Redis backups with version > 2.8.22 spin a child process (in replicas) when enough memory is available to create a snapshot. So, this mean redis doesn't fork the process (of creating snapshot) when enough memory isn't available.
- So, my question is how much is the enough memory for Redis to spin up a child process to create backups?
- Is there a way to know whether replicas in my Redis cluster is forking a child process to create backups or not?
- My Redis replicas has about 15 - 20% of available memory while creating the backups. Is this enough to not affect the read performance?
Some steps we took to mitigate the issue:
- Increase number of replicas
- Increase reserved-memory (to 10%).
But, both steps didn't mitigate the issue.
Does increase in reserved-memory help in improving the read performance?. As per the AWS docs (https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html#backups-performance) reserved-memory helps to not affect Write performance.
Other workaround I'm thinking is to add a new shard to cluster. Adding a new shard would increase the available/free memory of each Replica and thus it always guarantee (theoretically) the forking of child process to create snapshots.
But, we also don't want to have too many shards to our cluster as too many shards could reduce our current read performance.
So, are there any other steps to make the snapshots/backups creation not affect Read performance?