> For the complete documentation index, see [llms.txt](https://docs.iexexchanger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.iexexchanger.com/help-center/reshenie-problem/diagnostika/loading-redis-is-loading-the-dataset-in-memory.md).
# 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 и почему база стала слишком большой.
{% content-ref url="/pages/cCEoFDjTDIufy3NUEakd" %}
[Подключение к серверу по SSH](/help-center/upravlenie-serverom/podklyuchenie-k-serveru-po-ssh.md)
{% endcontent-ref %}
***
## Что нельзя делать сразу
Не выполняйте эти команды без диагностики:
```bash
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
Сначала проверьте статус сервиса:
```bash
systemctl status redis-server --no-pager -l
```
Если сервис называется иначе, найдите его:
```bash
systemctl list-units --type=service | grep -Ei 'redis|valkey'
```
Проверьте ответ Redis:
```bash
redis-cli PING
```
Нормальный ответ:
```
PONG
```
Если Redis ещё загружается, вместо `PONG` может вернуться ошибка `LOADING`.
## Проверка процесса загрузки
Чтобы понять, Redis ещё загружается или уже готов, выполните:
```bash
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:
```bash
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
Проверьте оперативную память:
```bash
free -h
```
Проверьте диск:
```bash
df -h
```
Проверьте размер Redis-файлов:
```bash
du -sh /var/lib/redis
ls -lh /var/lib/redis
ls -lh /var/lib/redis/appendonlydir 2>/dev/null
```
Также проверьте память Redis:
```bash
redis-cli INFO memory | grep -E 'used_memory_human|used_memory_peak_human|used_memory_rss_human|maxmemory_human|maxmemory_policy|mem_fragmentation_ratio'
```
И количество ключей:
```bash
redis-cli INFO keyspace
```
Важно смотреть не только RAM сервера, но и объём данных, который Redis реально хранит.
## Как понять, что хранится в Redis
Посмотрите базы Redis:
```bash
redis-cli INFO keyspace
```
Пример:
```
db0:keys=1000,expires=900
db1:keys=238000,expires=50
```
В этом примере во второй базе очень много ключей, но почти нет ключей с истечением срока.
Это значит, что в Redis могли накопиться постоянные ключи без TTL.
Это частая причина долгой загрузки Redis.
***
## Просмотр примеров ключей
Посмотреть примеры ключей в базе `0`:
```bash
redis-cli -n 0 --scan | head -n 30
```
Посмотреть примеры ключей в базе `1`:
```bash
redis-cli -n 1 --scan | head -n 30
```
Найти самые тяжёлые ключи:
```bash
redis-cli -n 1 --memkeys --memkeys-samples 100
```
Если команда `--memkeys` недоступна, используйте:
```bash
redis-cli -n 1 --bigkeys
```
## Проверка TTL у подозрительных ключей
Сначала найдите ключи по шаблону.
Например:
```bash
redis-cli -n 1 --scan --pattern '*snapshot*' | head -n 10
```
Проверьте TTL и размер нескольких ключей:
```bash
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`:
{% content-ref url="/pages/MDuqJRjp8L1cHG9i4sRB" %}
[Broken mention](broken://pages/MDuqJRjp8L1cHG9i4sRB)
{% endcontent-ref %}
```bash
grep -E '^(CACHE_|QUEUE_|SESSION_|REDIS_)' .env
```
Также можно посмотреть информацию приложения:
```bash
php artisan about
```
Если используются очереди:
```env
QUEUE_DRIVER=redis
```
или:
```env
QUEUE_CONNECTION=redis
```
Redis нельзя чистить грубо через `FLUSHALL`.
Если используется Horizon:
{% content-ref url="/pages/cCEoFDjTDIufy3NUEakd" %}
[Подключение к серверу по SSH](/help-center/upravlenie-serverom/podklyuchenie-k-serveru-po-ssh.md)
{% endcontent-ref %}
```bash
php artisan horizon:status
supervisorctl status
```
***
## Как безопасно чистить Redis
Правильный подход — удалять только понятные мусорные cache-ключи.
Сначала посчитайте, сколько ключей подходит под шаблон:
```bash
redis-cli -n 1 --scan --pattern 'ВАШ_PATTERN' | wc -l
```
Посмотрите примеры:
```bash
redis-cli -n 1 --scan --pattern 'ВАШ_PATTERN' | head -n 20
```
Если вы уверены, что это старый cache, удаляйте через `UNLINK`.
Рекомендуется использовать `UNLINK`, а не `DEL`.
`UNLINK` освобождает память асинхронно и меньше блокирует Redis.
```bash
redis-cli -n 1 --scan --pattern 'ВАШ_PATTERN' \
| xargs -r -L 100 redis-cli -n 1 UNLINK
```
После очистки проверьте память и ключи:
```bash
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`.
Сначала сделайте проверку без удаления:
```bash
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
```
Если число ожидаемое, можно удалить старые ключи:
```bash
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-файл:
```bash
redis-cli BGSAVE
```
Проверьте статус сохранения:
```bash
redis-cli INFO persistence | grep -E 'rdb_bgsave_in_progress|rdb_last_bgsave_status|rdb_last_save_time'
```
Проверьте размер Redis-файлов:
```bash
du -sh /var/lib/redis
ls -lh /var/lib/redis/dump.rdb
```
После успешного `BGSAVE` следующий старт Redis обычно будет быстрее, потому что файл `dump.rdb` станет меньше.
## Если не хватает оперативной памяти
Признаки проблемы:
```
OOM
Killed process redis-server
Out of memory
```
Проверьте системные логи:
```bash
journalctl -k --no-pager | grep -Ei 'oom|killed|out of memory|redis'
```
Проверьте память:
```bash
free -h
```
Временно можно добавить swap:
```bash
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:
```bash
systemctl stop redis-server
cp -a /var/lib/redis /root/redis-backup-$(date +%F-%H%M)
```
Проверьте RDB:
```bash
redis-check-rdb /var/lib/redis/dump.rdb
```
Проверьте, включён ли AOF:
```bash
redis-cli CONFIG GET appendonly
```
Если включён AOF, найдите файлы:
```bash
find /var/lib/redis -maxdepth 2 -type f \( -name '*.aof' -o -name '*.manifest' \) -ls
```
Проверка AOF:
```bash
redis-check-aof /var/lib/redis/appendonly.aof
```
Для Redis 7 путь может отличаться, если используется `appendonlydir`.
Команды с `--fix` используйте только после backup.
## Настройка maxmemory
Не ставьте `allkeys-lru` на общий Redis, где живут очереди.
Плохой вариант для общего Redis:
```conf
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 один общий, безопаснее использовать:
```conf
maxmemory 4gb
maxmemory-policy noeviction
```
Но это только ограничитель.
Главная задача — убрать мусорные ключи и исправить приложение, которое создаёт cache без TTL или без очистки старых данных.
***
## Рекомендуемая системная настройка
Для Redis рекомендуется включить `vm.overcommit_memory = 1`.
Выполните:
```bash
echo 'vm.overcommit_memory = 1' > /etc/sysctl.d/99-redis.conf
sysctl --system
```
Это снижает риск проблем при `BGSAVE` и fork-процессах Redis.
***
## После работ с Redis
После очистки или восстановления Redis перезапустите связанные процессы приложения.
Для Laravel/Horizon:
{% content-ref url="/pages/cCEoFDjTDIufy3NUEakd" %}
[Подключение к серверу по SSH](/help-center/upravlenie-serverom/podklyuchenie-k-serveru-po-ssh.md)
{% endcontent-ref %}
```bash
php artisan queue:restart
supervisorctl restart horizon laravel-worker
```
Для PHP-FPM сначала найдите сервис:
```bash
systemctl list-units --type=service | grep -i fpm
```
Примеры:
```bash
systemctl reload php8.2-fpm
```
или для FastPanel PHP 8.4:
```bash
systemctl reload fp2-php84-fpm.service
```
## Короткий чек-лист
1. Проверить Redis:
```bash
redis-cli PING
redis-cli INFO persistence
```
2. Проверить память и базы:
```bash
redis-cli INFO memory
redis-cli INFO keyspace
```
3. Проверить размер файлов:
```bash
du -sh /var/lib/redis
ls -lh /var/lib/redis
```
4. Найти большие или массовые ключи:
```bash
redis-cli -n 1 --memkeys --memkeys-samples 100
redis-cli -n 1 --scan --pattern '*snapshot*' | wc -l
```
5. Не делать:
```bash
FLUSHALL
FLUSHDB
```
6. Удалять только понятные старые cache-ключи через:
```bash
SCAN + UNLINK
```
7. После очистки выполнить:
```bash
redis-cli BGSAVE
```
8. Исправить приложение, чтобы такие ключи больше не копились.
***
## Частые ошибки
Redis долго грузится после каждого рестарта
Скорее всего, в Redis слишком много данных.
Проверьте:
```bash
redis-cli INFO keyspace
du -sh /var/lib/redis
```
Найдите массовые ключи и проверьте TTL.
Redis показывает LOADING и не отвечает на PING
Это может быть нормальным, если загрузка ещё идёт.
Проверьте:
```bash
redis-cli INFO persistence
```
Если `loading_loaded_perc` растёт, дождитесь завершения.
Redis падает при загрузке
Проверьте память и системные логи:
```bash
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 или без ограничения хранения.