Оптимизация настроек Redis

Игорь Грегорченко

01.03.2020 14:32

Чтобы получить наилучшую производительность необходима тонкая настройка, которая уменьшит вероятность непредвиденных ошибок, ограничений и пиковых нагрузок. Это касается всех частей системы, железа и базы данных.

С чего начать

Любую оптимизацию необходимо начинать с профилирования и тестирования приложения под высокими нагрузками. Также не забывайте о серверной оптимизации, правильной настройке Nginx и дополнительной оптимизации Ubuntu-сервера. Такой подход сохранит нервы и упростит дальнейшую процедуру тюнинга.

Когда Redis настроена и готова к работе, рекомендуем проверить ее при помощи встроенного теста:

$ redis-benchmark -q -n 100000 -c 50 -P 12

# Вывод будет таким
PING_INLINE: 641025.62 requests per second                                                             
PING_BULK: 694444.50 requests per second                                                               
SET: 434782.59 requests per second                                                                     
GET: 520833.34 requests per second                                                                     
INCR: 456621.00 requests per second                                                                    
LPUSH: 462962.94 requests per second                                                                   
LPOP: 440528.62 requests per second                                                                    
SADD: 418410.06 requests per second                                                                    
SPOP: 549450.56 requests per second                                                                    
LPUSH (needed to benchmark LRANGE): 473933.66 requests per second                                      
LRANGE_100 (first 100 elements): 37397.16 requests per second                                          
LRANGE_300 (first 300 elements): 10351.97 requests per second                                          
LRANGE_500 (first 450 elements): 6939.14 requests per second                                           
LRANGE_600 (first 600 elements): 5518.76 requests per second                                           
MSET (10 keys): 88105.73 requests per second

# Выполнит 100 000 запросов от 50 клиентов по 12 команд одновременно

Бэкапы

В Redis реализовано два persistence-режима: RDB и AOF.

При включении RDB система создает компактные снэпшоты данных в заданные интервалы времени. Это хороший подход для восстановления информации в случае сбоя. Бэкапы пишутся в параллельном процессе при помощи команды fork(), который в случае большой БД затратен по ресурсам и времени. Кроме этого, в случае неожиданного выключения сервера, все данные, которые не были записаны или находились в процессе создания резервной копии, будут утеряны.

AOF представляет собой лог операций, которые выполняют клиенты. Метод расшифровывается как Append Only File, то есть все новые данные добавляются к уже имеющимся данным, причем, каждую секунду по умолчания. Так что в случае сбоя потери будут минимальны. Но подход немного медленнее RDB, лог-файл существенно больше, производительность зависит от параметров fsync.

Для настройки Redis нужно отредактировать файл конфигурации /etc/redis/redis.conf:

# Параметры по умолчанию
save 900 1
save 300 10
save 60 10000

dir /var/redis/ # Директория хранения
dbfilename dump.rdb # Имя файла 
rdbcompression yes # Включение сжатия

# По умолчанию включен режим RDB

Хотите максимальной производительности — отключите persistence полностью. Или же настройте частоту создания снэпшотов. По умолчанию установлены параметры:

Создать копию, если было хотя бы одно изменение в течение 15 минут (900 секунд);
Создать копию, если в течение 5 минут (300 секунд) было хотя бы 10 изменений;
Создать копию, если за минуту было 10 000 изменений.

Еще один вариант — используйте репликацию.

Дополнительные параметры

Чтобы избежать узких мест, рекомендуем увеличить количество соединений, которые слушает сокет:
tcp-backlog 65536
# Значение по умолчанию — 511

Также стоит обратить внимание на разрешенное количество клиентов:

maxclients 10000
# Если слишком низкое, то появится ошибка ‘max number of clients reached’

Redis работает с ОЗУ, используя весь максимум доступной памяти. Так что есть смысл ограничить разрешенный объем, чтобы другие процессы сервера также могли выполняться:

maxmemory 1572864000
# Указание в байтах

Поиск проблем при помощи INFO

Просмотр статистики работы Redis поможет найти ошибки и проблемные места. К примеру, можно оценить скорость кэширования:

$ redis-cli INFO stats |grep keyspace
keyspace_hits:1920
keyspace_misses:930

# Система явно не успевает

Таким способом отслеживайте лимит доступной памяти maxmemory через eviction ключей:

$ redis-cli INFO stats |grep evicted_keys
evicted_keys:11582

# Система упирается в доступный объем памяти

Также стоит подобрать наилучшую политику отклонения ключей (eviction policy):

maxmemory-policy allkeys-lru
# Указывать в файле конфигурации Redis

Доступно 6 параметров:

noeviction — возвращает ошибку;
allkeys-lru — отклоняет ключи, убирая наименее используемые ключи (least recently used (LRU);
volatile-lru — отклоняет ключи, удаляя наименее используемые, если установлен срок истечения;
allkeys-random — отклоняет ключи в случайном порядке;

volatile-random — отклоняет ключи в случайном порядке, если установлен срок истечения;
volatile-ttl — в первую очередь отклоняет ключи c наименьшим сроком истечения.

Самое главное

Для создания отказоустойчивой системы используйте репликацию. Отключение снэпшотов принесет заметный прирост производительности. Также стоит подобрать наилучшую eviction policy для вашего приложения.