Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
© 2022 ООО «Яндекс.Облако»
Yandex Managed Service for Redis
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Информация об имеющихся кластерах
    • Создание кластера
    • Изменение настроек кластера и базы данных
    • Подключение к базе данных
      • Подготовка к подключению
      • Подключение к нешардированному кластеру
      • Подключение к шардированному кластеру
    • Остановка и запуск кластера
    • Обновление версии Redis
    • Управление хостами кластера
    • Управление шардами
    • Управление резервными копиями
    • Переключение мастера
    • Мониторинг состояния кластера и хостов
    • Просмотр логов кластера
    • Удаление кластера
  • Практические руководства
    • Хранение сессий PHP в Managed Service for Redis
    • Миграция базы данных в Managed Service for Redis
  • Концепции
    • Взаимосвязь ресурсов сервиса
    • Классы хостов
    • Сеть в Managed Service for Redis
    • Шардирование
    • Резервные копии
    • Репликация и отказоустойчивость
    • Поддерживаемые клиенты
    • Управление памятью в Managed Service for Redis
    • Доступные команды Managed Service for Redis
    • Квоты и лимиты
    • Типы хранилища
    • Техническое обслуживание
    • Настройки Redis
  • Управление доступом
  • Правила тарификации
    • Действующие правила
    • Архив
      • До 1 февраля 2020 года
  • Справочник API
    • Аутентификация в API
    • gRPC (англ.)
      • Overview
      • BackupService
      • ClusterService
      • ResourcePresetService
      • OperationService
    • REST (англ.)
      • Overview
      • Backup
        • Overview
        • get
        • list
      • Cluster
        • Overview
        • addHosts
        • addShard
        • backup
        • create
        • delete
        • deleteHosts
        • deleteShard
        • get
        • getShard
        • list
        • listBackups
        • listHosts
        • listLogs
        • listOperations
        • listShards
        • move
        • rebalance
        • rescheduleMaintenance
        • restore
        • start
        • startFailover
        • stop
        • streamLogs
        • update
        • updateHosts
      • ResourcePreset
        • Overview
        • get
        • list
      • Operation
        • Overview
        • get
  • История изменений
  • Вопросы и ответы
    • Общие вопросы
  1. Концепции
  2. Управление памятью в Managed Service for Redis

Управление памятью в Managed Service for Redis

Статья создана
Yandex Cloud
  • Повышение производительности и стабильности процесса Redis
  • Стабильное создание резервных копий

Для пользовательских данных на хостах кластера Managed Service for Redis выделяется 75% от общего объема оперативной памяти. Оставшаяся память резервируется для служебных нужд процесса Redis. Объем памяти, доступной для пользовательских данных, определяется через параметр maxmemory при запуске процесса Redis.

Резервирование памяти на хосте позволяет:

  • повысить производительность и стабильность процесса Redis;
  • организовать стабильное создание резервных копий.

Повышение производительности и стабильности процесса Redis

Наличие резерва памяти позволяет использовать на хостах кластера Managed Service for Redis настройку ядра Linux vm.overcommit_memory = 0. С такой настройкой процесс Redis минимизирует обращения к файлу подкачки и использует при выполнении служебных операций зарезервированную память. Это повышает производительность и обеспечивает стабильную работу процесса Redis, в т. ч. при репликации и создании резервных копий.

Стабильное создание резервных копий

Резервные копии в Managed Service for Redis создаются на основе консистентного снимка памяти процесса. Снимок создается в результате копирования исходного процесса Redis с помощью системного вызова fork().

Использование fork() снижает потребление RAM, т. к. исходный процесс Redis и его копия совместно используют одинаковые страницы памяти. Наличие резерва RAM и настройка vm.overcommit_memory = 0 делает использование fork() более безопасным — создание копий не влияет на производительность основного процесса Redis.

При работе fork() используется механизм Copy-on-Write: если совместно используемая страница памяти изменяется, то создается ее копия, куда записываются изменения. Поэтому, если во время создания резервной копии ведется запись в кластер, обновленные и новые данные занимают дополнительное место в памяти. Таким образом, при интенсивной записи память хостов может быть исчерпана даже при наличии резерва RAM. В этом случае операционная система хоста завершит процессы Redis по причине нехватки памяти (OOM, out-of-memory). Redis станет недоступен на этом хосте, а операции репликации и резервного копирования будут прерваны. Чтобы избежать этого:

  • выберите такое время начала резервного копирования, когда кластер наименее нагружен;
  • увеличьте объем оперативной памяти, повысив класс хостов.

Была ли статья полезна?

Language / Region
© 2022 ООО «Яндекс.Облако»
В этой статье:
  • Повышение производительности и стабильности процесса Redis
  • Стабильное создание резервных копий