Как на самом деле стойкость Redis RDB работает за сценой?

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

На данный момент понимание:

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

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

Цитата из документации

RDB часто требуется fork (), чтобы сохранять на диске дочерний процесс. Fork () может занять много времени, если набор данных большой, и может привести к тому, что Redis перестанет обслуживать клиентов на несколько миллисекунд или даже на одну секунду, если набор данных очень большой, а производительность процессора невысока. AOF также нуждается в fork (), но вы можете настроить частоту перезаписи журналов без ущерба для долговечности.

Я знаю, как работает fork, насколько мне известно. Когда родительский процесс разветвляется, он создает новый дочерний процесс, и мы можем разрешить выполнение некоторого кода, который дочерний процесс будет выполнять на основе его pid, или мы можем предоставить ему новый исполняемый файл, с которым он будет работать с помощью exec ( ) системный вызов.

но вещи, которые я не понимаю, как это будет тяжелая задача, когда размер набора данных больше?

Думаю, я знаю ответ, но не уверен в этом

Цитируется по этой ссылке https://www.bottomupcs.com/fork_and_exec.xhtml

Когда процесс вызывает fork, тогда

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

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

Я правильно понимаю?


person Thinker    schedule 06.10.2017    source источник
comment
Лично я предпочитаю метод AOF, он более надежный и быстрый. По моему опыту, оба метода требуют x2 памяти, но метод RDB требует больше ввода-вывода для HD, поэтому, если ваша БД большая, это займет время ...   -  person h0x91B    schedule 06.10.2017
comment
Я ответил, почему fork может быть медленным и почему сохранение rdb может быть медленным, но вы можете сделать свой вопрос более конкретным и менее беспорядочным и обновить заголовок вашего вопроса.   -  person nnog    schedule 06.10.2017


Ответы (1)


Когда стандартная ветвь вызывается с копированием при записи, ОС все равно должна копировать все записи таблицы страниц, что может занять некоторое время, если у вас маленькие страницы размером 4 КБ и огромный набор данных, это то, что замедляет фактическое время fork ().

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

Больше чтения:

Более быстрое разветвление больших процессов в Linux?

http://kirkwylie.blogspot.co.uk/2008/11/linux-fork-performance-redux-large.html

person nnog    schedule 06.10.2017