Оптимизация настроек Redis
Чтобы получить наилучшую производительность необходима тонкая настройка, которая уменьшит вероятность непредвиденных ошибок, ограничений и пиковых нагрузок. Это касается всех частей системы, железа и базы данных.
С чего начать
Любую оптимизацию необходимо начинать с профилирования и тестирования приложения под высокими нагрузками. Также не забывайте о серверной оптимизации, правильной настройке 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 для вашего приложения.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: