На производительность чтения кластера Redis (версия> 2.8.22 в AWS), которое у нас есть, в последнее время влияют регулярные запланированные снимки / резервные копии. Я вижу увеличение операций чтения в задержке (или тайм-ауты) во время создания резервных копий redis.
В соответствии с документацией AWS Резервные копии Redis с версией> 2.8.22 запускают дочерний процесс (в репликах), когда достаточно памяти для создания снимка. Таким образом, это означает, что redis не разворачивает процесс (создания снимка), когда недостаточно памяти.
- Итак, мой вопрос: насколько памяти Redis достаточно, чтобы ускорить дочерний процесс для создания резервных копий?
- Есть ли способ узнать, разветвляет ли реплики в моем кластере Redis дочерний процесс для создания резервных копий или нет?
- Мои копии Redis имеют около 15–20% доступной памяти при создании резервных копий. Этого достаточно, чтобы не влиять на производительность чтения?
Некоторые шаги, которые мы предприняли для смягчения проблемы:
- Увеличение количества реплик
- Увеличение зарезервированной памяти (до 10%).
Но оба шага не помогли решить проблему.
Помогает ли увеличение зарезервированной памяти улучшить производительность чтения? . Согласно документам AWS (https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html#backups-performance) зарезервированная память помогает не влиять на производительность записи.
Другой обходной путь, я думаю , чтобы добавить новый осколок в кластер . Добавление нового сегмента увеличило бы доступную / свободную память каждой реплики и, таким образом, всегда гарантировало (теоретически) разветвление дочернего процесса для создания снимков.
Но мы также не хотим иметь слишком много шардов в нашем кластере, так как слишком много шардов может снизить нашу текущую производительность чтения.
Итак, есть ли другие шаги, чтобы создание снимков / резервных копий не влияло на производительность чтения?