Как решить проблему истечения срока действия ключа в Redis

Реализация activeExpireCycle изменилась между версиями Redis 2.4 и 3.2. В Redis 2.4 каждая база данных проверялась при каждом запуске, а в Redis 3.2 было достигнуто максимальное количество баз данных, которые можно было проверить. В версии 3.2 также появилась возможность быстрой проверки базы данных. «Медленный» запускается по таймеру, а «быстрый» запускается перед проверкой событий в цикле событий. Период быстрого истечения будет возвращаться раньше при определенных условиях, а также имеет более низкие пороговые значения времени ожидания и функции выхода. Сроки также проверяются чаще. Всего к этой функции было добавлено 100 строк кода.

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

То, как вы масштабируете и обрабатываете сегменты, делает запуск Redis в Twitter уникальным. У нас есть ключевые пространства, содержащие миллионы ключей. Это редкость для пользователей Redis. Осколки представлены пространством ключей, поэтому каждый экземпляр Redis может иметь несколько осколков. В нашем экземпляре Redis много ключевых пробелов. Шардинг в сочетании с масштабом Twitter создает плотный бэкэнд с большим количеством ключей и баз данных.

Мы также хотели исследовать изменения между версиями Redis. В новой версии Redis представлена ​​переменная CRON_DBS_PER_CALL. Эта переменная устанавливает максимальное количество баз данных для проверки при каждом запуске этого cron. Чтобы проверить действие этой переменной, мы просто закомментировали эти строки.

//if (dbs_per_call > server.dbnum || timelimit_exit)dbs_per_call = server.dbnum;

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

99,9% в микросекундах. Немодифицированный Redis выше, а модифицированный Redis ниже.

Мы начали исследовать, почему комментирование этой строки имеет такое огромное значение. Поскольку это оператор if, наше первое подозрение — предсказание ветвления. мы используем

gcc’s__builtin_expect

Затем мы смотрим на сгенерированную сборку, чтобы увидеть, что именно происходит.

Мы компилируем заявление о если в три важных инструкция MOV, CMP и JG. MOV загрузит некоторую память в реестр, CMP будет сравнивать два регистрия и установить другой регистр на основе результата, JG выполнит условный скачок на основе значения другого регистра. Код для перехода к тому, что будет кодом в блоке IF или Block. Я вынимаю заявление IF и поместил собранную сборку в Redis. Затем я проверяю влияние каждой инструкции, комментируя различные линии. Я проверил инструкцию MOV, чтобы увидеть, была ли проблема производительности с загрузкой памяти или кэш CPU, но не нашел никакой разницы. Я проверил команду CMP и не нашел никакой разницы. Когда я запускаю тест с включенной директивой JG, задержка возвращается на немодифицированный уровень. После нахождения этого я проверил, если бы это был просто прыжок, или определенная инструкция JG. Я добавил безоговорочную инструкцию JMP JMP, которая прыгает, а затем прыгает назад, чтобы запустить код без штрафа производительности.

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

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

На этом графике показано использование памяти первым развернутым кластером. Верхняя линия (розовая), скрытая оранжевым цветом, представляет собой среднее использование памяти кластера. Оранжевая верхняя строка — это экземпляр элемента управления. Средняя часть диаграммы — тренд нового изменения. В третьем разделе показан пример перезапуска элемента управления по сравнению со светло-желтым цветом. После перезапуска использование памяти элементом управления быстро увеличивается.