Лучшая настройка EC2 для сервера redis

Ответ 1

EC2, вероятно, не самая лучшая среда для запуска Redis на виртуализованном оборудовании, но она популярна, и есть несколько точек, которые нужно знать, чтобы получить лучшее от Redis на этой платформе.

Я один из авторов http://redis.io/topics/benchmarks и http://redis.io/topics/latency, которые охватывают большую часть темы, представленные ниже. Это всего лишь краткое изложение основных моментов.

Плата за виртуализацию

Это не относится к EC2, но Redis значительно медленнее при работе на виртуальной машине (в терминах максимальной поддерживаемой пропускной способности). Это связано с тем, что для основных операций Redis не добавляет больших накладных расходов на системные вызовы epoll/read/write, необходимые для обработки клиентских подключений (например, memcached или другие эффективные хранилища ключей/значений). Системные вызовы обычно более дороги для VM, и они представляют значительную часть активности Redis (особенно в тестах). В этих условиях сокращение на 50% максимальной пропускной способности по сравнению с голым металлом не является чем-то необычным.

Конечно, это также зависит от качества гипервизора. Для EC2 используется Xen.

Бенчмаркинг в хороших условиях

Бенчмаркинг может быть сложным, особенно на платформе EC2. Часто забывается, что необходимо обеспечить правильную конфигурацию как для клиентского теста, так и для сервера. Например, не запускайте redis-benchmark на микро-экземпляре с процессором, который, скорее всего, будет отключен Amazon, а также нацелен на ваш сервер Redis. Обе машины одинаково важны для получения максимальной максимальной пропускной способности.

Собственно, для оценки производительности Redis вам необходимо:

• запустите redis-benchmark локально (на той же машине, что и сервер), предполагая, что у вас более одного ядра vCPU.

• дистанционно запускать redis-benchmark (с другой виртуальной машины) на машине, конфигурация QoS которой эквивалентна серверной машине

Таким образом, вы можете оценить и сравнить производительность машин и сети.

В EC2 у вас будут лучшие результаты с экземплярами M3 второго поколения (или с высокой памятью или с использованием экземпляров кластера), поэтому вы можете воспользоваться HVM (аппаратной виртуализацией) вместо того, чтобы полагаться на более медленную паравиртуализацию.

Проблема с вилкой

Это не относится к EC2, но к Xen: forking большой процесс может быть очень медленным на Xen (он выглядит лучше с kvm). Для Redis это большая проблема, если вы планируете использовать постоянство: оба параметра сохранения (RDB или AOF) требуют, чтобы основной поток зависал и запускал фоновое сохранение или переписывание процессов.

В некоторых случаях лавина fork может заморозить цикл событий Redis в течение нескольких секунд. Чем больше памяти управляется экземпляром Redis, тем больше латентности.

В EC2 обязательно используйте экземпляр с поддержкой HVM (M3, high-memory, cluster), это смягчит проблему.

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

Конфигурация сохранения

Это ключевой момент, чтобы получить хорошую производительность от Redis (как на виртуальной машине, так и на голом металле). Поэтому, пожалуйста, найдите время, чтобы внимательно прочитать http://redis.io/topics/persistence

Если вы используете RDB, имейте в виду, что механизм копирования памяти на запись запускает дублирование страниц после того, как будет сохранен фоновый процесс сохранения. Поэтому вам нужно убедиться, что для Redis достаточно памяти, плюс некоторый запас, чтобы справиться с COW. объем дополнительной памяти зависит от вашей рабочей нагрузки. Чем больше вы пишете в этом экземпляре, тем больше вам потребуется дополнительная память.

Обратите внимание, что запись файла может также потреблять некоторую память (из-за кеша файловой системы), поэтому во время сохранения фона Redis вам необходимо учитывать память Redis, служебные данные COW и размер файла дампа.

Машина, работающая на сервере Redis, никогда не должна меняться. Если это произойдет, результат будет катастрофическим. В отличие от некоторых других магазинов, Redis не поддерживает виртуальную память.

В Linux не забудьте установить разумные системные параметры: vm.overcommit_memory = 1 и vm.swappiness = 0 (или очень низкое значение в любом случае). Не используйте старые версии ядра: они довольно плохи для обеспечения низкой swappiness (в результате чего происходит обмен файлами с большим файлом).

Если вы используете AOF, просмотрите параметры fsync. Это компромисс между сырой производительностью и долговечностью операций записи. Вам нужно сделать выбор и определить стратегию.

Вам также необходимо ознакомиться с вариантами хранения EC2. На некоторой виртуальной машине у вас есть выбор между эфемерным хранилищем и EBS. На некоторых других у вас есть только EBS.

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

EBS - это удаленное хранилище: он может использовать стандартную пропускную способность сети, выделенную для виртуальной машины, и влиять на максимальную пропускную способность Redis. Если вы планируете использовать EBS, попробуйте выбрать опцию "EBS-optimized", чтобы установить QoS между стандартной сетью и ссылками на хранилище.

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