В любой системе баз данных производительность всегда является проблемой, с которой чаще всего сталкиваются администраторы баз данных и разработчики, особенно в производственной и большой среде. Стоит отметить, что простая настройка производительности Redis может значительно ускорить работу вашего приложения. При настройке Redis необходимо учитывать все уровни: от клиента до сервера и обратно.
Настройка производительности должна быть постепенной, изменяемой и чувствительной. Это не постоянный курс действий, который будет служить до бесконечности. При любых изменениях, особенно радикальных, которые включают в себя приложение, программное и аппаратное обеспечение, а также сеть, необходимо проводить тщательные тесты, а затем корректировать настройку в соответствии с влиянием изменений. Любые изменения в конфигурации Redis могут повлиять на его производительность, и это влияние может либо ухудшить, либо увеличить производительность. Поэтому настройка, особенно в производственной среде, требует тщательных и спланированных решений. В то же время, перед настройкой важно выполнить предварительные действия и проверить текущую производительность вашей базы данных.
Контрольный список производительности Redis перед настройкой может выглядеть следующим образом:
- Проверьте работоспособность ваших хостов, просмотрев данные сервера
- Убедитесь, что ваша виртуализация работает нормально, проанализировав метрики виртуальных машин
- Оптимизируйте доступ к базе данных с помощью данных приложения
- Проанализируйте влияние взаимодействия базы данных с сетью с помощью сетевых данных.
Управление памятью
Redis - это хранилище данных in-memory с некоторыми дополнительными опциями персистентности. Если вы планируете сравнивать его с транзакционными серверами (MySQL, PostgreSQL, MongoDB и т.д. ...), то вам следует рассмотреть возможность активации AOF и выбрать подходящую политику fsync.
Отключение THP
Скорость оперативной памяти и пропускная способность памяти кажутся менее критичными для глобальной производительности, особенно для небольших объектов. Однако для больших объектов (>10 КБ) это может стать заметным. Обычно для оптимизации Redis не очень выгодно покупать дорогие модули быстрой памяти. Например, в реальном сценарии ядро Linux имеет включенные прозрачные огромные страницы. Redis несет большие потери времени после использования вызова fork для сохранения на диске. Огромные страницы являются причиной следующей проблемы:
- При вызове fork создаются два процесса с общими огромными страницами.
- В загруженном экземпляре несколько запусков цикла событий вызовут команды, нацеленные на несколько тысяч страниц, что вызовет копирование-запись почти всей памяти процесса.
- Это приведет к большим задержкам и использованию большого объема памяти.
Обязательно отключите прозрачные страницы с помощью следующей команды:
| 1 | echo never > /sys/kernel/mm/transparent_hugepage/enabled |
Избегание OOM
Redis работает медленнее на виртуальной машине по сравнению с работой без виртуализации на том же оборудовании. Если у вас есть возможность запустить Redis на физической машине, это предпочтительнее. Однако это не означает, что Redis работает медленно в виртуализированных средах, его производительность по-прежнему очень высока, а большинство серьезных проблем с производительностью, с которыми вы можете столкнуться в виртуализированных средах, связаны с избыточным выделением ресурсов, нелокальными дисками с высокой задержкой или старым программным обеспечением гипервизора с медленной реализацией системных вызовов fork.
Включение overcommit_memory
Чтобы повысить безопасность вашего Redis, лучше всего избегать проблем с нехваткой памяти. Рекомендуется установить параметры ядра, чтобы избежать OOM. Если значение overcommit memory равно 0, то существует вероятность, что ваш Redis получит ошибку OOM (Out of Memory). Чтобы избежать этого, вы можете сделать следующее:
| 1 2 3 | echo 1 > /proc/sys/vm/overcommit_memory ## Установите его на постоянной основе echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf |
Стоит отметить, что 32- и 64-битные экземпляры Redis не имеют одинакового объема памяти.
Устанавливайте своппинг с наименьшим весом
Redis в значительной степени полагается на большинство ресурсов вашей памяти. Если память сильно потребляется активными процессами, запущенными на хосте базы данных, где размещен Redis, он начнет использовать пространство подкачки, которое использует диск в качестве ресурса для хранения временного распределения памяти. Хотя это означает, что он все еще позволяет вашим задачам завершаться или выполняться без завершения работы всей системы, это ухудшает производительность Redis от медленной до резкой, а это не то, чего бы вам хотелось, особенно в загруженной среде с высоким трафиком. Чтобы избежать этого, выполните следующее:
| 1 2 3 | echo 1 > /proc/sys/vm/swappiness ## Установите его на постоянной основе echo 'vm.swappiness = 1' >> /etc/sysctl.conf |
Выбор правильных распределителей памяти
В зависимости от платформы, Redis может быть скомпилирован с различными распределителями памяти (libc malloc, jemalloc, tcmalloc), которые могут иметь различное поведение в плане скорости работы, внутренней и внешней фрагментации. Если вы не компилировали Redis самостоятельно, вы можете использовать команду INFO для проверки поля mem_allocator. Обратите внимание, что большинство бенчмарков не работают достаточно долго, чтобы создать значительную внешнюю фрагментацию (в отличие от производственных экземпляров Redis).
Аллокаторы памяти, поддерживаемые Redis, действительно имеют различия, когда речь идет о результатах фрагментации памяти при выделении больших блоков памяти или даже небольших блоков памяти. Если вам нужна производительность, то для настройки Redis необходимо провести тест с собственными реальными данными и сделать бенчмарк, чтобы выбрать наиболее подходящий распределитель памяти для ваших данных.
Использование памяти
Redis будет использовать всю доступную память на сервере, если это не настроено. Такова природа Redis по умолчанию, поэтому имеет смысл настроить его так, чтобы он занимал около 75-85% памяти, выделенной для Redis. Убедитесь, что Redis работает не на общем сервере, а на выделенном окружении. Чтобы изменить это, отредактируйте ваш redis.conf, как показано ниже,
| 1 2 | # Устанавливаем значение 16Gib maxmemory 17179869184 |
Кроме того, вы можете выполнить команду ниже, чтобы установить это значение динамически и также применить изменения в вашем redis.conf,
| 1 2 | CONFIG SET maxmemory <целое значение> CONFIG REWRITE |
Настройка конфигурации Redis
Существуют важные параметры, которые вы можете установить для настройки производительности Redis. Эти параметры помогают увеличить производительность Redis, особенно при обработке большого трафика и управлении большими объектами данных.
TCP-KeepAlive
Keepalive - это метод, позволяющий использовать одно и то же TCP-соединение для HTTP-общения вместо того, чтобы открывать новое при каждом новом запросе.
Проще говоря, если функция keepalive выключена, Redis будет открывать новое соединение для каждого запроса, что замедлит его работу. Если keepalive включен, то Redis будет использовать одно и то же TCP-соединение для запросов.
Чтобы включить TCP keepalive, отредактируйте файл конфигурации Redis и включите или обновите это значение, как показано ниже:
| 1 2 3 | ## Редактирование файла конфигурации по умолчанию /etc/redis/redis.conf # Обновите значение до 0 tcp-keepalive 0 |
Отключите сохранение данных redis на диск в redis.conf
Redis попытается сохранить данные на диск. Несмотря на то, что redis выполняет вилку для этого процесса, он все равно замедляет работу.
Закомментируйте строки, начинающиеся с save
| 1 2 3 | #save 900 1 #save 300 10 #save 60 10000 |
Если вам нужно сохранять данные, добавьте дополнительный диск и используйте его для сохранения данных, так как это приведет к меньшему замедлению.
TCP-backlog
В новых версиях redis собственное значение backlog установлено на 511, и вам потребуется увеличить его, если у вас много соединений. Для этого отредактируйте файл конфигурации redis и добавьте, например, следующее,
| 1 2 3 4 | # TCP listen() backlog. # В средах с высоким числом запросов в секунду вам нужен высокий бэклог, чтобы. # обязательно поднять значение somaxconn и tcp_max_syn_backlog tcp-backlog 65536 |
Установите maxclients
По умолчанию установлено значение 10000, но если у вас много соединений, вам может потребоваться большее значение. В противном случае, если у вас мало ресурсов, но вы работаете на эффективном кластере Redis с горизонтальным шардингом, то уменьшите значение, чтобы убедиться, что оно не создает узких мест. Для этого просто отредактируйте или измените значение в конфигурации Redis следующим образом
| 1 2 3 | # Как только лимит будет достигнут, Redis закроет все новые соединения, отправляя. # ошибку "достигнуто максимальное количество клиентов". maxclients 10000 |
Персистентность Redis
При использовании Redis для хранения персистентных данных лучшим вариантом для оптимальной и производительной работы Redis является включение как AOF, так и RDB. Использование только RDB или AOF имеет свои недостатки и может поставить вас в критическое положение. Это общее указание на то, что вам следует использовать оба метода сохранения, если вы хотите получить степень безопасности данных, сравнимую с тем, что может предоставить вам PostgreSQL.
Если вы очень заботитесь о своих данных, но все же можете смириться с несколькими минутами потери данных в случае катастроф, вы можете просто использовать только RDB. Есть много пользователей, использующих только AOF, но сообщество Redis не рекомендует этого делать, поскольку наличие снимка RDB время от времени является отличной идеей для резервного копирования базы данных, более быстрого перезапуска и в случае ошибок в движке AOF.
Также вероятно, что в будущем выпуске Redis они, вероятно, закончат объединением AOF и RDB в единую модель персистентности и в долгосрочном плане.