LOADING Redis is loading the dataset in memory

Ошибка: LOADING Redis is loading the dataset in memory

означает, что Redis уже запустился, но ещё загружает данные с диска в оперативную память.

Пока загрузка не закончилась, сайт или панель управления могут временно получать ошибку Redis.

Чаще всего это происходит после:

• перезагрузки сервера;
• рестарта Redis;
• восстановления данных из dump.rdb;
• восстановления данных из AOF;
• слишком большого объёма данных в Redis.

Это не всегда поломка.

Если Redis загрузился за несколько секунд и ошибка исчезла — это нормальная ситуация.

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

Подключение к серверу по SSH

---

Что нельзя делать сразу

Не выполняйте эти команды без диагностики:

FLUSHALL
FLUSHDB
rm -f /var/lib/redis/dump.rdb
rm -rf /var/lib/redis
systemctl restart redis-server много раз подряд

Redis может хранить не только cache.

В нём могут быть:

• очереди;
• Horizon;
• locks;
• rate limits;
• сессии;
• временные данные приложения;
• runtime-данные модулей.

Если очистить Redis полностью, можно потерять важные рабочие данные.

Проверка статуса Redis

Сначала проверьте статус сервиса:

systemctl status redis-server --no-pager -l

Если сервис называется иначе, найдите его:

systemctl list-units --type=service | grep -Ei 'redis|valkey'

Проверьте ответ Redis:

redis-cli PING

Нормальный ответ:

PONG

Если Redis ещё загружается, вместо PONG может вернуться ошибка LOADING.

Проверка процесса загрузки

Чтобы понять, Redis ещё загружается или уже готов, выполните:

redis-cli INFO persistence | grep -E 'loading|loading_loaded_perc|loading_eta_seconds|rdb|aof'

Если Redis ещё загружается, можно увидеть:

loading:1
loading_loaded_perc:45.23
loading_eta_seconds:60

Это означает:

• loading:1 — загрузка ещё идёт;
• loading_loaded_perc — процент загрузки;
• loading_eta_seconds — примерное время до завершения.

Если процент растёт, лучше дождаться окончания загрузки.

Когда Redis готов, будет:

loading:0

---

Проверка логов Redis

Проверьте последние логи Redis:

journalctl -u redis-server -n 200 --no-pager

В логах обращайте внимание на строки:

Loading
Ready to accept connections
OOM
Killed
No space left on device
RDB
AOF
corrupt
Bad file format

Что это может означать:

OOM / Killed

Не хватает оперативной памяти.

No space left on device

Закончилось место на диске.

corrupt / Bad file format

Возможно, повреждён файл Redis.

Ready to accept connections

Redis успешно загрузился и готов принимать подключения.

Проверка RAM, диска и размера Redis

Проверьте оперативную память:

free -h

Проверьте диск:

df -h

Проверьте размер Redis-файлов:

du -sh /var/lib/redis
ls -lh /var/lib/redis
ls -lh /var/lib/redis/appendonlydir 2>/dev/null

Также проверьте память Redis:

redis-cli INFO memory | grep -E 'used_memory_human|used_memory_peak_human|used_memory_rss_human|maxmemory_human|maxmemory_policy|mem_fragmentation_ratio'

И количество ключей:

redis-cli INFO keyspace

Важно смотреть не только RAM сервера, но и объём данных, который Redis реально хранит.

Как понять, что хранится в Redis

Посмотрите базы Redis:

redis-cli INFO keyspace

Пример:

db0:keys=1000,expires=900
db1:keys=238000,expires=50

В этом примере во второй базе очень много ключей, но почти нет ключей с истечением срока.

Это значит, что в Redis могли накопиться постоянные ключи без TTL.

Это частая причина долгой загрузки Redis.

---

Просмотр примеров ключей

Посмотреть примеры ключей в базе 0:

redis-cli -n 0 --scan | head -n 30

Посмотреть примеры ключей в базе 1:

redis-cli -n 1 --scan | head -n 30

Найти самые тяжёлые ключи:

redis-cli -n 1 --memkeys --memkeys-samples 100

Если команда --memkeys недоступна, используйте:

redis-cli -n 1 --bigkeys

Проверка TTL у подозрительных ключей

Сначала найдите ключи по шаблону.

Например:

redis-cli -n 1 --scan --pattern '*snapshot*' | head -n 10

Проверьте TTL и размер нескольких ключей:

for k in $(redis-cli -n 1 --scan --pattern '*snapshot*' | head -n 5); do
  echo "$k"
  redis-cli -n 1 TTL "$k"
  redis-cli -n 1 MEMORY USAGE "$k"
done

Если TTL равен:

-1

значит ключ никогда не истекает.

Если таких ключей тысячи или сотни тысяч, Redis будет постоянно расти и долго загружаться после рестарта.

---

Проверка Redis в Laravel

Для Laravel-проектов сначала проверьте .env:

Файлы сайта в FastPanel

grep -E '^(CACHE_|QUEUE_|SESSION_|REDIS_)' .env

Также можно посмотреть информацию приложения:

php artisan about

Если используются очереди:

QUEUE_DRIVER=redis

или:

QUEUE_CONNECTION=redis

Redis нельзя чистить грубо через FLUSHALL.

Если используется Horizon:

Подключение к серверу по SSH

php artisan horizon:status
supervisorctl status

---

Как безопасно чистить Redis

Правильный подход — удалять только понятные мусорные cache-ключи.

Сначала посчитайте, сколько ключей подходит под шаблон:

redis-cli -n 1 --scan --pattern 'ВАШ_PATTERN' | wc -l

Посмотрите примеры:

redis-cli -n 1 --scan --pattern 'ВАШ_PATTERN' | head -n 20

Если вы уверены, что это старый cache, удаляйте через UNLINK.

Рекомендуется использовать UNLINK, а не DEL.

UNLINK освобождает память асинхронно и меньше блокирует Redis.

redis-cli -n 1 --scan --pattern 'ВАШ_PATTERN' \
  | xargs -r -L 100 redis-cli -n 1 UNLINK

После очистки проверьте память и ключи:

redis-cli INFO memory | grep used_memory_human
redis-cli INFO keyspace

---

Пример: старые snapshot-ключи

Частая проблема — cache создаёт версионные snapshot-ключи и не удаляет старые поколения.

Пример:

some-cache-snapshot-1
some-cache-snapshot-2
some-cache-snapshot-3
...
some-cache-snapshot-100000

Правильная логика — хранить только последние несколько поколений.

Например, последние 3.

Сначала сделайте проверку без удаления:

CURRENT=119236
KEEP_FROM=$((CURRENT - 2))

redis-cli -n 1 --scan --pattern '*snapshot-*' \
  | awk -F'-snapshot-' -v keep="$KEEP_FROM" '($2 + 0) < keep {print}' \
  | wc -l

Если число ожидаемое, можно удалить старые ключи:

redis-cli -n 1 --scan --pattern '*snapshot-*' \
  | awk -F'-snapshot-' -v keep="$KEEP_FROM" '($2 + 0) < keep {print}' \
  | xargs -r -L 100 redis-cli -n 1 UNLINK

После этого обязательно исправьте генератор cache в приложении.

Иначе Redis снова вырастет.

Пересоздание RDB-файла после очистки

После удаления лишних ключей пересоздайте RDB-файл:

redis-cli BGSAVE

Проверьте статус сохранения:

redis-cli INFO persistence | grep -E 'rdb_bgsave_in_progress|rdb_last_bgsave_status|rdb_last_save_time'

Проверьте размер Redis-файлов:

du -sh /var/lib/redis
ls -lh /var/lib/redis/dump.rdb

После успешного BGSAVE следующий старт Redis обычно будет быстрее, потому что файл dump.rdb станет меньше.

Если не хватает оперативной памяти

Признаки проблемы:

OOM
Killed process redis-server
Out of memory

Проверьте системные логи:

journalctl -k --no-pager | grep -Ei 'oom|killed|out of memory|redis'

Проверьте память:

free -h

Временно можно добавить swap:

fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Важно: swap не решает основную причину.

Если Redis хранит гигабайты cache из-за ошибки приложения, нужно чистить мусорные ключи и исправлять логику cache.

Если повреждён RDB или AOF

Сначала сделайте backup:

systemctl stop redis-server
cp -a /var/lib/redis /root/redis-backup-$(date +%F-%H%M)

Проверьте RDB:

redis-check-rdb /var/lib/redis/dump.rdb

Проверьте, включён ли AOF:

redis-cli CONFIG GET appendonly

Если включён AOF, найдите файлы:

find /var/lib/redis -maxdepth 2 -type f \( -name '*.aof' -o -name '*.manifest' \) -ls

Проверка AOF:

redis-check-aof /var/lib/redis/appendonly.aof

Для Redis 7 путь может отличаться, если используется appendonlydir.

Команды с --fix используйте только после backup.

Настройка maxmemory

Не ставьте allkeys-lru на общий Redis, где живут очереди.

Плохой вариант для общего Redis:

maxmemory-policy allkeys-lru

Почему это опасно:

Redis может удалить ключи очередей, Horizon, locks или другие важные runtime-данные.

Лучше разделять Redis по назначению:

Redis #1: queues / Horizon / locks
maxmemory-policy noeviction

Redis #2: cache
maxmemory-policy allkeys-lru

Если Redis один общий, безопаснее использовать:

maxmemory 4gb
maxmemory-policy noeviction

Но это только ограничитель.

Главная задача — убрать мусорные ключи и исправить приложение, которое создаёт cache без TTL или без очистки старых данных.

---

Рекомендуемая системная настройка

Для Redis рекомендуется включить vm.overcommit_memory = 1.

Выполните:

echo 'vm.overcommit_memory = 1' > /etc/sysctl.d/99-redis.conf
sysctl --system

Это снижает риск проблем при BGSAVE и fork-процессах Redis.

---

После работ с Redis

После очистки или восстановления Redis перезапустите связанные процессы приложения.

Для Laravel/Horizon:

Подключение к серверу по SSH

php artisan queue:restart
supervisorctl restart horizon laravel-worker

Для PHP-FPM сначала найдите сервис:

systemctl list-units --type=service | grep -i fpm

Примеры:

systemctl reload php8.2-fpm

или для FastPanel PHP 8.4:

systemctl reload fp2-php84-fpm.service

Короткий чек-лист

1. Проверить Redis:

redis-cli PING
redis-cli INFO persistence

1. Проверить память и базы:

redis-cli INFO memory
redis-cli INFO keyspace

1. Проверить размер файлов:

du -sh /var/lib/redis
ls -lh /var/lib/redis

1. Найти большие или массовые ключи:

redis-cli -n 1 --memkeys --memkeys-samples 100
redis-cli -n 1 --scan --pattern '*snapshot*' | wc -l

1. Не делать:

FLUSHALL
FLUSHDB

1. Удалять только понятные старые cache-ключи через:

SCAN + UNLINK

1. После очистки выполнить:

redis-cli BGSAVE

1. Исправить приложение, чтобы такие ключи больше не копились.

---

Частые ошибки

Redis долго грузится после каждого рестарта

Скорее всего, в Redis слишком много данных.

Проверьте:

redis-cli INFO keyspace
du -sh /var/lib/redis

Найдите массовые ключи и проверьте TTL.

Redis показывает LOADING и не отвечает на PING

Это может быть нормальным, если загрузка ещё идёт.

Проверьте:

redis-cli INFO persistence

Если loading_loaded_perc растёт, дождитесь завершения.

Redis падает при загрузке

Проверьте память и системные логи:

free -h
journalctl -k --no-pager | grep -Ei 'oom|killed|out of memory|redis'

После очистки Redis снова растёт

Значит причина не устранена в приложении.

Нужно найти код или модуль, который создаёт ключи без TTL или не удаляет старые поколения cache.

Можно ли просто удалить dump.rdb

Без понимания содержимого — нет.

Так можно потерять важные данные Redis.

Сначала нужно понять, что хранится в Redis: только cache или также очереди, locks, сессии и runtime-данные.

---

Главная мысль

Ошибка: LOADING Redis is loading the dataset in memory часто является не самой проблемой, а симптомом.

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

Правильное решение — не перезапускать Redis много раз подряд, а понять, какие ключи раздувают базу, удалить только безопасный мусор и исправить приложение, которое создаёт эти ключи без TTL или без ограничения хранения.