MISCONF Redis настроен для сохранения снимков RDB
во время записи в Redis ( SET foo bar ) Я получаю следующую ошибку:
MISCONF Redis настроен для сохранения снимков RDB, но в настоящее время не удается сохранить на диске. Команды, которые могут изменять набор данных: нетрудоспособный. Пожалуйста, проверьте журналы Redis для получения подробной информации об ошибке.
в основном я понимаю, что проблема в том, что redis не может сохранять данные на диске, но не знаю, как избавиться от проблема.
и следующий вопрос имеет ту же проблему, она давно заброшена без ответов и, скорее всего, без попыток решить проблему.
18 ответов
в случае, если вы столкнулись с ошибкой, и некоторые важные данные не могут быть отброшены на работающем экземпляре redis (проблемы с разрешениями для rdb файл или его каталог неправильно, или заканчивается дисковое пространство), вы всегда можете перенаправить rdb файл для записи в другом месте.
вы можете остановить его, пытаясь сохранить снимок:
это быстрый обходной путь, но если вы заботитесь о данных, вы используете его для, Вы должны проверить, чтобы убедиться, почему bgsave не удалось в первую очередь.
могут быть ошибки во время процесса bgsave из-за нехватки памяти. Попробуйте это (из redis background save FAQ)
слишком кратко об ответе. откройте терминал и введите следующие команды
если вы работаете на машине linux, также проверьте права доступа к файлам и папкам базы данных.
БД и путь к нему можно получить через:
CONFIG получить dbfilename
для меня, введя config set stop-writes-on-bgsave-error no в оболочке и перезапуск Redis решили проблему.
запустите сервер Redis в каталоге, где Redis имеет разрешения на запись
ответы выше определенно решат вашу проблему, но вот что на самом деле происходит:
что еще хуже, redis также, вероятно, не позволит вам закрыть сервер либо до тех пор, пока он не сможет создать файл rdb для обеспечения надлежащего сохранения данных.
(теперь, если вы нужно сохранить дамп.файл rdb в каталоге, в котором вы запустили сервер, затем вам нужно будет изменить разрешения для каталога, чтобы redis мог писать в него. Вы можете найти stackoverflow для того, как это сделать).
таким образом, когда вам нужно redis для другого проекта, файл дампа будет создан в каталоге текущего проекта, а не в каталоге проекта жестко закодированного пути.
эта ошибка возникает из-за сбоя BGSAVE. Во время BGSAVE Redis разветвляет дочерний процесс для сохранения данных на диске. Хотя точную причину отказа BGSAVE можно проверить из журналов (обычно при /var/log/redis/redis-server.log на машинах с Linux), но много раз БДАЛ не потому, что вилка не может выделить память. Много раз вилка не может выделить память (хотя машина имеет достаточно оперативной памяти) из-за конфликтной оптимизации ОС.
Redis схема сохранения фона зависит от семантики копирования на запись fork в современных операционных системах: Redis forks (создает дочерний процесс), который является точной копией родительского. Дочерний процесс сбрасывает БД на диск и, наконец, завершает работу. Теоретически ребенок должен использовать столько же памяти, сколько и родитель, являющийся копией, но на самом деле благодаря семантике copy-on-write, реализованной большинством современных операционных систем, Родительский и дочерний процесс будет общие страницы памяти. Страница будет дублироваться только при изменении дочернего или родительского элемента. Поскольку теоретически все страницы могут изменяться во время сохранения дочернего процесса, Linux не может заранее сказать, сколько памяти займет ребенок, поэтому, если параметр overcommit_memory установлен в нулевую вилку, произойдет сбой, если не будет столько свободного ОЗУ, сколько требуется, чтобы действительно дублировать все родительские страницы памяти, в результате чего, если у вас есть набор данных Redis 3 ГБ и всего 2 ГБ свободной памяти, потерпеть неудачу.
установка overcommit_memory в 1 говорит Linux, чтобы расслабиться и выполнить вилку в более оптимистичном режиме распределения, и это действительно то, что вы хотите для Redis.
Redis не нужно столько памяти, сколько ОС думает, что это делает для записи на диск, поэтому может упреждающе сбой вилки.
Почему Redis меняет свои параметры dir и dbfilename и падает с ошибкой MISCONF Redis is configured to save RDB snapshots?
[80927] 24 Jan 07:04:41.643 * 1 changes in 900 seconds. Saving.
[80927] 24 Jan 07:04:41.648 * Background saving started by pid 52245
[52245] 24 Jan 07:04:41.649 # Error moving temp DB file on the final destination: Is a directory
[80927] 24 Jan 07:04:41.748 # Background saving error
Ручками забиваю пути к дампу:
но спустя какое-то время, пути сбиваются снова:
при попытке изменения политики выделения памяти в sysctl под рутом, получаю:
sysctl vm.overcommit=1
vm.overcommit: 0
sysctl: vm.overcommit=1: Operation not permitted
Ответ службы поддержки:
Здравствуйте.
На данной системе виртуализации данный параметр изменить нельзя.
Буду, конечно, переносить проекты на другой сервер. если ничего с падениями поделать нельзя. хотя этот сценарий очень нежелателен..
redis 127.0.0.1:6379> INFO
# Server
redis_version:2.6.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_mode:standalone
os:FreeBSD 8.3-STABLE amd64
arch_bits:64
multiplexing_api:kqueue
gcc_version:4.2.1
process_id:80927
run_id:9f7e6b9b08f49c85f335abe0e21e8d8c4f094d71
tcp_port:6379
uptime_in_seconds:79856
uptime_in_days:0
hz:10
lru_clock:658666
# Clients
connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
# Memory
used_memory:1164464
used_memory_human:1.11M
used_memory_rss:1164464
used_memory_peak:1244280
used_memory_peak_human:1.19M
used_memory_lua:31744
mem_fragmentation_ratio:1.00
mem_allocator:libc
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1453621516
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
# Stats
total_connections_received:290
total_commands_processed:1077
instantaneous_ops_per_sec:0
rejected_connections:0
expired_keys:2
evicted_keys:0
keyspace_hits:722
keyspace_misses:36
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:346
# Replication
role:master
connected_slaves:0
# CPU
used_cpu_sys:106.24
used_cpu_user:5.95
used_cpu_sys_children:136.74
used_cpu_user_children:14.78
# Keyspace
db0:keys=1,expires=0
db1:keys=4,expires=3
Redis — главное хранилище? Что за хрень?!
Redis это размещаемое в памяти хранилище ключ-значение, обычно используемое для кэшей и подобных механизмов ускорения сетевых приложений. Мы, тем не менее, храним все наши данные в Redis — в нашей главной базе данных.
Сеть полна предупреждений и предостерегающих повествований об использовании подобного подхода. Есть ужасающие истории о потере данных, исчерпании памяти или людях неспособных эффективно управлять данными в Redis, вы, возможно, интересуетесь «О чём вы вообще думаете?». Так вот, наш рассказ, почему мы всё же решили использовать Redis и как мы преодолели все эти проблемы.
Прежде всего, я хотел бы подчеркнуть что большинство приложений вовсе не должны обращать внимания на костыли использованные, что бы пойти таким путём. Это было важно для нашего сценария использования, но мы можем быть граничным случаем.
Redis как хранилище данных
Redis быстр. Когда я говорю быстр, я имею в виду Быстр с заглавной буквы Б. Это по существу memcached с более продуманными типами данных, нежели просто строковые значения. Даже некоторые продвинутые операции такие, как пересечение множеств, выборка диапазонов zset, ослепительно быстры. Есть все поводы использовать Redis для быстроменяющихся активно запрашиваемых данных. Он довольно часто используется в качестве кэша, который может быть перестроен по данным из резервной базы данных. Это мощная замена memcached предоставляющая более продвинутое кэширование для различных видов хранимых вами данных.
Как и в memcached, всё находится в памяти. Redis сохраняется на диск, но он не сохраняет данные синхронно с тем как вы записываете их. Есть две причины из-за которых Redis в качестве главного хранилища — отстой:
— Вы вынуждены умещать все свои данные в памяти, и…
— Если сервер откажет между двумя синхронизациями с диском — вы потеряете всё что сидело в памяти.
Из-за этих двух проблем Redis обосновался в компактной нише в качестве временного кэша для данных которыми вы можете пожертвовать, но не главного хранилища данных. Предоставляя быстрый доступ к часто необходимым данным с возможностью перестроения при необходимости.
Недостаток использования более традиционных хранилищ за Redis заключается в затыке с производительностью этих хранилищ. Вам приходится жертвовать производительностью чтобы убедиться, что данные сохранены на диск. Совершенно нормальная сделка для почти каждого приложения. Вы можете получить великолепную производительность по чтению и «хорошую» производительность по записи. Я должен пояснить, что «хорошая» для меня вполне вероятно может быть безумно быстрая для большинства людей. Достаточно сказать, что «хорошая» производительность по записи должна удволетворить большинство, кроме самых высоко нагруженных приложений.
Я полагаю, что вы можете выполнить запрос на запись в Redis а потом сохраниться при помощи реляционного хранилища, но тогда остаются те же риски падения Redis и потери данных очереди записи.
Что нам нужно?
Moot предлагается как полностью бесплатный продукт. Нам, таким образом, необходимо иметь возможность обрабатывать крупные нагрузки на очень небольшом количестве железа. Если нам нужна куча больших баз данных для форума обслуживающего несколько миллионов пользователей в месяц, то нет никаких способов остаться бесплатным сервисом. Поскольку мы хотим, что бы Moot был и бесплатным и неограниченным, мы вынуждены были оптимизировать до предела.
Мы могли бы просто избежать этого установив какие-нибудь ограничения на бесплатные сервисы и брать деньги за просмотр страниц или постов. Не знаю как вы, но я, в общем, не люблю продукты, которые бесплатны «пока вы не раскрутитесь». Скажем, вы настроили форум, а потом что-то на вашем сайте станет вирусным. Внезапно, вас ошарашат счётом за превышение бесплатного уровня. И вот то, что начиналось как развлечение, из-за внезапной популярности вашего блога о теории заговоров, превращается в ужас грядущего счёта. Вас наказывают за ваш успех. Это то, чего мы хотели бы избежать.
Мы так же могли бы решить монетизироваться размещая рекламу, и позволив себе более высокие эксплуатационные расходы. Это, тем не менее, полностью расходится с нашим базовыми ценностями как бизнеса. По нашему мнению, если кто-то собирается размещать рекламу на вашем сайте, это должны быть вы а не мы. Moot должен предлагаться без условий, ограничений и приписок.
Принимая во внимание всё вышесказанное, необходимо достичь непревзойдённой производительности для постинга и чтения не взирая на инженерные сложности. Это базис для нашей возможности работать. У нас была изначальная цель, чтобы все вызовы API обрабатывались менее чем за 10мс даже под высокой нагрузкой, и даже тогда, когда обрабатываются большие сложные списки или поиски. Redis, очевидно, может обеспечить нам такую производительность, но две большие проблемы никуда не делись: Как, блин, мы сможем использовать Redis, если у нас могут быть сотни гигабайт данных, и что делать с падением сервера?
Что же теперь делать?
Так началось наше исследование способов проектирования с учётом этих ограничений. У нас с самого начала было точное понимание какими будут задачи у Moot, и наших ценностей как компании, поэтому нам повезло иметь возможность обдумать эти особенности до написания первых строчек кода. Я полагаю что эти проблемы были бы чрезмерно сложны, если бы мы решили пойти этим путём, имея множество готового кода.
Все данные в памяти. Блин.
Это самая сложна из двух проблем. Количество памяти, которое может быть на одном компьютере, конечно. Наибольшее количество на EC2 это 244-гигабайтный сервер. Хотя это по прежнему конечный объём, это довольно хороший лимит для начала. К сожалению, при этом ваш 16-ядерный сервер будет использовать только одно ядро для Redis. Что ж, как на счёт добавления по подчинённому процессу Redis на каждое ядро? Тогда у вас осталось по 15 ГБ памяти на каждый экземпляр. Опять фигня! Это плохое ограничение, если вы хотите иметь возможность выжать из сервера мощность. Это не достаточно данных для сервиса хостинга.
Мы решили спроектировать наше Redis-хранилище с самого начала разделённым среди множества Redis кластеров. Мы хэшируем и разделяем данные в блоки содержащие все структуры, относящиеся к данному сегменту данных. Данные сильно разделены с самого начала и мы можем по необходимости создавать новые блоки быстро и просто.
Для разбивки данных мы храним таблици хэшей и адресов примерно так:
Когда поступают данные, мы вычисляем хэш на основе наших требований к связности данных, потом мы проверяем в shards.map был ли он назначен какому-нибудь блоку, и если да — мы можем направить вызовы на тот блок.
Если хэш ещё не приписан к какому либо блоку, мы создаём список доступных блоков множа их в соответствии с весом. Если например выполнить:
Список будет выглядеть как-то так:
После этого мы назначаем случайный блок из списка, сохраняем в карту распределения и идём далее.
Применяя такую схему мы можем легко контролировать сколько данных поступает в блоки, добавлять новые блоки или даже исключать блоки из рассмотрения, если видим, что они заполнены.
Реально мы начали с сотен блоков так что нечего беспокоиться о нагрузке на сервера и ограничениях памяти.
Отдельные блоки остаются очень малыми. Один сервер содержит много блоков в базах данных Redis и, если эти блоки увеличиваются в размерах, мы легко можем разделить базы Redis на независимые экземпляры. Скажем у нас экземпляр Redis с 100 блоками, мы видим, что некоторые блоки увеличиваются в размере и мы разделяем Redis на два экземпляра по 50 блоков каждый. Мы можем точно настроить веса чтобы поддерживать распределение между блоками в реальном времени.
Самая сложная часть, это точно определить то, как вы сегментируете ваши данные. Это очень специфично и наш вариант сегментации, возможно, тема для отдельного поста.
Такая стратегия хранения должна разрабатываться в приложении с самого начала. Часто люди пытаются разделять данные, которые так не спроектированы, в этом то и загвоздка для их использования Redis. Поскольку мы чётко знали, что ограничение памяти будет проблемой, мы смогли спроектировать решение в самом ядре нашей системы управления данными, ещё до того как мы написали хоть одну строчку кода.
Падения сервера
Разобраться с отказами оказалось, смешно сказать, легче. У нас для кластера Redis было 3 разные роли:
— Мастер, где происходили почти все операции на запись,
— Подчинённый, гда происходили почти все чтения,
— Хранитель, выделенный для сохранения данных.
Мастер и подчинённый работают в общем как и любые другие в кластере Redis. В этом нет ничего интересного. Что мы сделали нового, это то что в каждом кластере есть по 2 сервера, используемых в качестве хранителей. Эти сервера:
— Не принимают никаких входящих соединений и не несут никакой нагрузки Redis запросов, кроме простой репликации
— Хранение AOF в ежесекундном режиме
— Ежечасный снимок RDB
— Синхронизируют AOF и RDB в S3
В виду того, что параметры производительности для хранения могут несколько различаться, один сервер хранитель может обработать различное количество блоков. Мы просто запускаем по одному экземпляру на каждый блок, который должен храниться. Другими словами, нет необходимости в отношении 1 к 1 между блоками и серверами с ролью хранителя.
У нас два этих сервера расположены в различных зонах доступности, так что даже если одна из зон выходит из строя, у нас есть работающий актуальный сервер-хранитель.
Таким образом, чтобы нам потерять данные необходим довольно большой отказ в EC2 и даже тогда, мы потеряем только около секунды данных.
Если вы рассматриваете сценарий нарушения связности сети, когда мастер может быть изолирован от подчинённых, его можно нивелировать проверкой репликации подчинённых(установить произвольный ключ в произвольное значение и проверить, обновились ли данные у подчинённого) Если мастер изолирован, мы останавливаем запись: Согласованность и Устойчивость к потере связности за счёт Доступности. Redis Sentinel тоже мог бы помочь нам с этим, но Sentinel был выпущен позже того, как мы реализовали большую часть системы. Мы не исследовали, как Sentinel мог бы вписаться бы в наше уравнение.
Конечный результат
В конце концов, мы смогли построить систему, которая под нагрузкой выполняет вызовы API за приблизительно 2 мс.
Значение 2 мс — при обслуживании нашего самого тяжёлого API-вызова, инициализационного API-вызова.
Многие наши запросы обслуживаются гораздо быстрее ( лайки например часто за 0.6-0.7 мс). Мы можем исполнять 1000 API запросов в секунду на одном API сервере. И для построения страницы требуется один API вызов. В замер включены все наши проверки данных, управление блоками, аутентификация, управление сессиями, соединениями, сериализация JSON и так далее.
Многое из этого заслуга не только ЭТИХ решений для Redis. Есть ещё несколько трюков для того, чтобы система производительно работала под высокой параллельной нагрузкой. Один из этик трюков в том, что почти половина нашего кода написана на Lua и работает прямо в Redis. Это другая вещь, которую в общем говорят не делать. Что касается того, как и почему у нас тысячи строк кода на Lua — подождите следующего поста о нашем применении Redis.
Взгляните на нашу реальную производительность, мы запустились пару дней назад, и получили неплохой начальный всплеск. Мы обслуживали 50 API вызовов в секунду и процессор нашего главного API сервера (мы до сих пор посылаем весь трафик на один) был полностью в простое. Вот графики, начиная с нашего запуска до момента написания поста.
Во время наших пиковых нагрузок всё тихо. Вы можете заметить пару всплесков, когда мы накатывали хотфиксы, но в остальном ни шороха. Более поздние всплески соответствуют обновлениям системы, исправлениям и другим проводимым системным работам. Общая нагрузка так же включает увеличенные накладные расходы на логгирование которое мы вели в период начального бета теста.
Пояснение: я ссылаюсь на API сервер как на замеряемый, так как наш сервер приложений и Redis сервер это одно и тоже. API сервер несёт на себе как несколько блоков, так и приложение. Идея была в том, чтобы маршрутизировать трафик на сервер где в основном расположен этот блок, чтобы воспользоваться unix-сокетами для подключения к Redis. Это позволят избегать излишнего сетевого трафика поэтому нет особого различия между Сервером приложений, Redis мастером и Redis подчинённым. Любой API сервер может обработать любой запрос, просто мы даём гораздо больший приоритет мастер серверу задействованного сегмента данных. Все серверы — серверы приложений, и все серверы — мастера для каких-то блоков и подчинённые для других.
tl;dr
Есть множество причин не использовать Redis как главное хранилище на жёстком диске, но если, по каким-то причинам, ваш вариант использования требует этого, вам необходимо начинать с самого начала. Вам стоит проектировать ваши данные разделёнными и помнить о дополнительной стоимости выделенных серверов хранения.
MISCONF Redis настроен для сохранения снимков RDB
во время записи в Redis ( SET foo bar ) Я получаю следующую ошибку:
MISCONF Redis настроен для сохранения снимков RDB, но в настоящее время не удается сохранить на диске. Команды, которые могут изменить набор данных нетрудоспособный. Пожалуйста, проверьте журналы Redis для получения подробной информации об ошибке.
в основном я понимаю, что проблема в том, что redis не может сохранить данные на диске, но понятия не имею, как избавиться от проблема.
также следующий вопрос имеет ту же проблему, он давно заброшен без ответов и, скорее всего, не пытается решить проблему.
18 ответов:
в случае, если вы столкнулись с ошибкой и некоторые важные данные не могут быть отброшены на запущенном экземпляре redis (проблемы с разрешениями для rdb файл или его каталог неправильно, или не хватает места на диске), вы всегда можете перенаправить rdb файл для записи в другом месте.
вы можете остановить его, пытаясь сохранить снимок:
Это быстрый обходной путь, но если вы заботитесь о данных, которые вы используете для него, вы должны проверить, чтобы убедиться, почему bgsave не удалось в первую очередь.
могут быть ошибки во время процесса bgsave из-за нехватки памяти. Попробуйте это (из redis background save FAQ)
слишком кратко об ответе. откройте терминал и введите следующие команды
в случае, если вы работаете на машине linux, также проверьте права доступа к файлам и папкам базы данных.
БД и путь к нему можно получить через:
CONFIG получить dbfilename
для меня, введя config set stop-writes-on-bgsave-error no в оболочке и перезапуск Redis решили проблему.
запустите сервер Redis в каталоге, где Redis имеет права на запись
ответы выше, безусловно, решить вашу проблему, но вот что на самом деле происходит:
что еще хуже, redis также, вероятно, не позволит вам закрыть сервер, пока он не сможет создать файл rdb для обеспечения надлежащего сохранения данных.
(теперь, если вы нужно сохранить дамп.файл rdb в каталоге, в котором вы запустили сервер, затем вам нужно будет изменить разрешения для каталога, чтобы redis мог писать в него. Вы можете искать stackoverflow для того, как это сделать).
таким образом, когда вам нужен redis для другого проекта, файл дампа будет создан в каталоге вашего текущего проекта, а не в каталоге проекта жестко заданного пути.
эта ошибка возникает из-за сбоя BGSAVE. Во время BGSAVE Redis разветвляет дочерний процесс для сохранения данных на диске. Хотя точную причину сбоя BGSAVE можно проверить из журналов (обычно при /var/log/redis/redis-server.log на машинах с Linux), но много раз БДАЛ не потому, что вилка не может выделить память. Много раз вилка не может выделить память (хотя машина имеет достаточно оперативной памяти) из-за конфликтной оптимизации ОС.
как можно прочитать из Redis FAQ:
схема сохранения фона Redis основана на семантике копирования при записи fork в современных операционных системах: Redis forks (создает дочерний процесс), который является точной копией родительского. Дочерний процесс сбрасывает БД на диск и, наконец, завершает работу. Теоретически ребенок должен использовать столько же памяти, сколько и родитель, являющийся копией, но на самом деле благодаря семантике копирования на запись, реализованной большинством современных операционных систем, Родительский и дочерний процесс будут общие страницы памяти. Страница будет дублироваться только тогда, когда она изменяется в дочернем или родительском элементе. Поскольку в теории все страницы может измениться, в то время как дочерний процесс-это экономия, линукс не могу сказать заранее, сколько памяти ребенка, поэтому если overcommit_memory параметр установлен в ноль вилка будет выполнена, если есть столько свободной оперативной памяти, как это требуется, чтобы действительно дублировать все родительские страниц памяти, поэтому если у вас есть Redis для набора данных 3 ГБ оперативной и всего 2 ГБ свободной памяти это потерпеть неудачу.
установка overcommit_memory в 1 говорит, что Linux расслабляется и выполняет вилку более оптимистичным способом распределения, и это действительно то, что вы хотите для Redis.
Redis не нужно столько памяти, сколько ОС думает, что это делает для записи на диск, так что может упреждающе провалить вилку.
MISCONF Redis настроен на сохранение снимков RDB
Во время записи в Redis ( SET foo bar ) я получаю следующую ошибку:
MISCONF Redis настроен для сохранения снимков RDB, но в настоящее время не может сохраняться на диске. Команды, которые могут изменить набор данных, отключены. Пожалуйста, проверьте журналы Redis для деталей об ошибке.
В основном я понимаю, что проблема в том, что Redis не может сохранять данные на диске, но не знаю, как избавиться от проблемы.
Кроме того, следующий вопрос имеет ту же проблему, он давно оставлен без ответов и, скорее всего, без попыток решить проблему.
Если вы столкнулись с ошибкой и некоторые важные данные не могут быть сброшены на работающем экземпляре Redis (проблемы с rdb неправильными разрешениями для файла или его каталога или нехваткой места на диске), вы всегда можете перенаправить rdb файл для записи в другое место.
Это быстрый обходной путь, но если вы заботитесь о данных, для которых вы его используете, вам следует проверить, почему bgsave потерпел неудачу в первую очередь.
Во время процесса bgsave могут быть ошибки из-за нехватки памяти. Попробуйте это (из redis background сохранить FAQ)
Эта ошибка возникает из-за сбоя BGSAVE. Во время BGSAVE Redis разветвляет дочерний процесс для сохранения данных на диске. Хотя точная причина сбоя BGSAVE может быть проверена из журналов (обычно /var/log/redis/redis-server.log на Linux-машинах), но во многих случаях BGAVE дает сбой, потому что вилка не может выделить память. Много раз форк не может выделить память (хотя у машины достаточно ОЗУ) из-за противоречивой оптимизации ОС.
Как можно прочитать из Redis FAQ :
Схема фонового сохранения Redis опирается на семантику копирования при записи в современных операционных системах: Redis разветвляется (создает дочерний процесс), который является точной копией родительского. Дочерний процесс выгружает БД на диск и, наконец, завершает работу. Теоретически ребенок должен использовать столько же памяти, сколько родительский объект, являющийся копией, но на самом деле благодаря семантике копирования при записи, реализованной большинством современных операционных систем, родительский и дочерний процессы будут совместно использовать страницы общей памяти. Страница будет продублирована только тогда, когда она изменяется в дочернем или родительском элементе. Поскольку теоретически все страницы могут изменяться во время сохранения дочернего процесса, Linux не может заранее определить, сколько памяти займет дочерний процесс, поэтому, если для параметра overcommit_memory задано нулевое значение, ветвь не будет работать, если не будет столько свободной оперативной памяти, сколько требуется действительно дублировать все родительские страницы памяти,
Установка для overcommit_memory значения 1 говорит о том, что Linux расслабляется и выполняет форк в более оптимистичном режиме распределения, и это действительно то, что вам нужно для Redis.
Redis не требуется столько памяти, сколько операционная система думает, что она делает запись на диск, поэтому может превратиться в неудачу.
Чтобы решить это, вы можете:
Изменить /etc/sysctl.conf и добавить:
Затем перезапустите sysctl с помощью:
Перезагрузите ваш сервер Redis.
Я лично имел эту проблему после обновления Redis с Brew ( brew upgrade ). После перезагрузки ноутбука он сразу заработал.
в случае, если вы работаете на машине с linux, также перепроверьте права доступа к файлам и папкам базы данных.
БД и путь к нему можно получить через:
CONFIG GET dbfilename
Для меня ввод config set stop-writes-on-bgsave-error no в оболочку и перезапуск Redis решили проблему.
Запустите Redis Server в каталоге, где у Redis есть права на запись
Ответы выше определенно решат вашу проблему, но вот что на самом деле происходит:
Кажется, вы начали запускать сервер Redis в каталоге, где Redis не имеет правильных разрешений для создания dump.rdb файла.
Что еще хуже, redis также, вероятно, не позволит вам выключить сервер, пока он не сможет создать файл rdb для обеспечения надлежащего сохранения данных.
Чтобы решить эту проблему, вы должны зайти в активную среду клиента Redis, используя redis-cli и обновив dir ключ, и установить его значение в папке вашего проекта или в любой папке, для которой у пользователя без полномочий root есть права на сохранение. Затем запустите, BGSAVE чтобы вызвать создание dump.rdb файла.
(Теперь, если вам нужно сохранить файл dump.rdb в каталоге, в котором вы запустили сервер, вам нужно будет изменить разрешения для каталога, чтобы redis мог записывать в него. Вы можете выполнить поиск в stackoverflow, как это сделать. ).
Таким образом, когда вам понадобится redis для другого проекта, файл дампа будет создан в каталоге вашего текущего проекта, а не в каталоге проекта с жестко заданным путем.
Обнаружил эту ошибку и смог из журнала выяснить, что ошибка из-за нехватки места на диске. Все данные, которые были вставлены в моем случае, больше не были нужны. Поэтому я попытался сбросить. Поскольку процесс redis-rdb-bgsave был запущен, он также не позволял сбрасывать данные. Я выполнил следующие шаги и смог продолжить.
Процесс redis-rdb-bgsave больше не выполнялся после описанных выше шагов.
Я сталкивался с подобной проблемой, основной причиной этого было потребление памяти (RAM) redis. У моей машины EC2 было 8 ГБ оперативной памяти (около 7.4 доступно для потребления)
Когда моя программа работала, объем используемой оперативной памяти достигал 7,2 ГБ, оставляя едва ли
К вашему сведению: вам может понадобиться установить htop, чтобы сделать эту работу: sudo apt-get install htop
И предложение для людей, непосредственно вставляющих команду config, пожалуйста, немного пересмотрите программу и, по крайней мере, предупредите пользователя перед использованием таких команд. И как @Rodrigo упомянул в своем комментарии: «Не выглядит круто игнорировать ошибки».
