Redis выкидывает сессии Битрикс на пике и разлогинивает всех

На акции в чате поддержки — одна жалоба пачками: кабинет выкинул, «сессия истекла». Сайт открывается, CPU не красный, мониторинг зелёный. Пока ищете баг в авторизации Битрикса, причина часто уже после «успешного» переноса сессий в Redis вместе с кэшем: на пике общий инстанс упирается в память, и политика вытеснения выкидывает ключи сессий.

Это не история про файловые сессии и блокировки на диске. Сайт жив, HTTP часто 200, а жалобы звучат как массовый разлогин. Ниже — как это устроено, почему logical DB не спасает и что проверить в Redis, пока волна не повторилась на следующем пике.

Как выглядит инцидент

Типичная картина: один Redis обслуживает и кэш горячих запросов, и сессии. На пике память доходит до maxmemory, политика allkeys-lru начинает вытеснять ключи — в том числе сессионные. Пользователи теряют авторизацию массово, хотя страница открывается.

Отличия от сценария «сайт лёг / FPM busy»:

• сайт открывается, жалобы именно на logout / «сессия истекла» в пик;
• на Redis, куда пишутся сессии, растёт evicted_keys;
• used_memory упирается в maxmemory, политика семейства allkeys-*;
• в конфиге кэш и сессии смотрят на один host:port — один процесс.

После разнесения инстансов или смены политики под сессии разлогины на пике пропадают при том же трафике — если причина была в eviction.

Почему общий Redis с кэшем выкидывает сессии

Когда Redis превышает maxmemory, он вытесняет ключи по maxmemory-policy, пока память не уйдёт ниже лимита. Политики allkeys-* (allkeys-lru, allkeys-lfu, allkeys-random и другие) могут удалить любой ключ — в том числе сессионный.

В официальной документации Redis allkeys-lru — типичный выбор именно для кэша. Если на том же инстансе лежат и кэш, и «нужные» ключи вроде сессий, docs прямо советуют два отдельных инстанса, если это возможно. На практике под Битрикс часто ставят лимит памяти и allkeys-lru «для кэша», а потом в тот же процесс кладут сессии — и на пике получают волну разлогинов.

Гайды под Битрикс часто рекомендуют для кэша maxmemory + allkeys-lru и отключение persistence; для сессий — наоборот: noeviction («лучше ошибка записи, чем потеря сессии») и включённый persistence. Смешивать эти режимы на одном процессе нельзя: политика одна на весь инстанс.

Logical DB — не отдельная политика

Частая ловушка в гайдах: кэш в db = 0, сессии в db = 1 и формулировка про «разные политики вытеснения». В Redis maxmemory и maxmemory-policy задаются на весь инстанс, не на номер logical DB (SELECT 1). «Отдельная база» на том же процессе не даёт отдельную политику — на следующем пике разлогины вернутся.

Logical DB полезен против случайного FLUSHDB и для раздельного обзора ключей, но не заменяет второй процесс или контейнер со своим конфигом. Разные политики — это отдельный инстанс.

Смежный, но другой механизм: FLUSHDB на общей DB с кэшем тоже массово разлогинит. Это не LRU eviction, но симптом похож — проверяйте, что именно чистите.

Что проверить, когда всех разлогинило

1. CONFIG GET maxmemory и maxmemory-policy на том Redis, куда смотрят сессии.
2. INFO stats — растёт ли evicted_keys в окне пика и жалоб на разлогин; рядом имеют смысл keyspace_hits / keyspace_misses; при странном hit-rate смотрите рост evicted_keys vs expired_keys.
3. INFO memory — used_memory vs maxmemory (в human-виде: used_memory_human, maxmemory_human), плюс запас под copy-on-write при BGSAVE/RDB: fork может съесть дополнительную RAM, не упирайтесь в потолок впритык.
4. Совпадают ли host/port (и процесс) у cache и session в bitrix/.settings.php или в php.ini / FPM.
5. Есть ли TTL у сессионных ключей (TTL / OBJECT IDLETIME выборочно) против TTL у кэша.

В ядре Битрикса хранение сессии задаётся секцией 'session' в bitrix/.settings.php; если секции нет — работает дефолт PHP. Для Redis: тип redis, host, port; в кластере — список серверов. Альтернатива ядру: session.save_handler=redis и session.save_path с tcp://… (у phpredis есть параметр database; lifetime ключа связан с session.gc_maxlifetime).

Как развести сессии и кэш

Рабочие варианты из практики и документации:

• Два инстанса: кэш — allkeys-lru / allkeys-lfu; сессии — noeviction или volatile-lru со скользящим TTL. Persistence для сессий включают; для чистого кэша часто отключают.
• Один инстанс (компромисс): TTL только на ключи кэша + политика volatile-* (volatile-lru, volatile-ttl и т.п.) — вечные сессии без expire политика не трогает, пока есть volatile-кандидаты. Если кандидатов с expire нет, volatile-* ведёт себя как noeviction (ошибка на запись).

Ограничения, которые часто пропускают:

• noeviction на общем инстансе с раздувающимся кэшем на пике даст ошибки записи кэша или сессий — лечит разнесение нагрузки, а не «просто сменить строку политики».
• Вечные session-ключи + volatile-* + полная память → OOM на запись. В проде сессиям обычно ставят скользящий TTL (в обсуждениях встречается пример порядка 30 минут) и обновляют TTL при активности.
• Без persistence рестарт Redis с сессиями = массовый logout — отдельный класс инцидента, не путать с eviction на пике.
• Не копируйте гайд «для кэша» (allkeys-lru, save "") на инстанс, где уже лежат сессии.

Алерты, без которых инцидент видят только клиенты

Алерт только по CPU и HTTP этот сценарий не ловит: сайт «зелёный», а сессии уже вытесняются. Минимум по Redis с сессиями:

• рост evicted_keys на инстансе с сессиями — уже инцидент (ненулевой счётчик в окне пика);
• used_memory выше примерно 80% от maxmemory — ранний сигнал до волны разлогинов;
• сверка, что cache и session не смотрят в один процесс с политикой allkeys-*.

После миграции или restore отдельно проверьте host Redis/Memcache в .settings.php: свежий кейс на Хабре (август 2026) как раз про «сессии перестали работать» из‑за инфраструктуры в настройках — смежный риск после «успешного» переноса.

Частые вопросы

Почему на пике всех разлогинило, а сайт и CPU в порядке?

Часто общий Redis с кэшем упёрся в maxmemory, а политика allkeys-lru вытеснила и ключи сессий: страница открывается, авторизация «слетает». Смотрите рост evicted_keys и заполненность памяти на том инстансе, куда пишутся сессии — не только HTTP и CPU.

Хватит ли разнести кэш и сессии по db0 и db1 на одном Redis?

Нет. maxmemory и maxmemory-policy действуют на весь процесс, а не на номер logical DB. Разные политики вытеснения — это отдельные инстансы (процессы или контейнеры) со своим конфигом; db0/db1 не заменяют разнесение.

Какую политику ставить для сессий: noeviction или volatile?

Для выделенного инстанса сессий часто берут noeviction («лучше ошибка записи, чем потеря сессии») или volatile-lru/volatile-ttl со скользящим TTL. На общем инстансе с кэшем allkeys-lru опасен для сессий; noeviction без разнесения нагрузки на пике даст ошибки записи — нужен отдельный инстанс или строгий volatile-only для кэша.

Какие метрики Redis смотреть при жалобах на разлогин?

В INFO stats — evicted_keys (и при странном hit-rate — hits/misses и expired_keys); в INFO memory — used_memory vs maxmemory. Ненулевой рост evicted_keys на Redis с сессиями в окне пика — сигнал инцидента; алерт около 80% заполнения maxmemory помогает поймать проблему раньше клиентов.

Как BX Pulse помогает заметить проблему раньше

BX Pulse следит за доступностью и техническим состоянием проектов на 1С-Битрикс и помогает обнаруживать аномалии до обращения клиента — в том числе сценарии, где сайт отвечает, а пользователи теряют сессии на пике. Добавьте первый сайт и настройте уведомления: https://bx-monitor.ru/.