Каковы потенциальные узкие места AOF

1. Когда Redis использует подпроцесс fork для перезаписи файла AOF, существует потенциальный риск блокировки.

1. Разветвить дочерний процесс

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

Но дочерний процесс fork должен скопировать необходимые структуры данных процесса, одна из которыхскопировать таблицу страниц памяти(таблица индексов отображения виртуальной памяти и физической памяти), этот процесс копирования будет потреблять много ресурсов ЦП, весь процесс будет заблокирован до завершения копирования, время блокировки зависит от объема памяти всего экземпляра,Чем больше экземпляр, тем больше таблица страниц памяти и тем дольше время блокировки форка..

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

Когда процесс родитель-потомок действительно разделит память?

«Реалистическое копирование», как следует из названия, заключается в копировании реальных данных в память только тогда, когда происходит запись.Во время этого процесса родительский процесс также может иметь риск блокировки, что является сценарием, описанным ниже..

2. Сценарии, в которых родительский процесс выполняет запись при перезаписи AOF.

Дочерний процесс из fork указывает на то же адресное пространство памяти, что и родительский процесс.В это время дочерний процесс может выполнить перезапись AOF и записать все данные в памяти в файл AOF.

Но в это время родительский процесс все еще будет иметь записанный трафик.Если родительский процесс оперирует существующим ключом, то родительский процесс фактически скопирует данные памяти, соответствующие ключу, и подаст заявку на новое пространство памяти, так что постепенно. Со временем данные памяти родительского и дочернего процессов начинают разделяться, и у родительского и дочернего процессов постепенно появляются свои независимые области памяти. Поскольку память выделяется в единицах страниц, значение по умолчанию равно 4 КБ.Если родительский процесс оперирует большим ключом в это время, повторное обращение к большому блоку памяти займет больше времени, что может привести к риску блокировки.

Кроме того, если операционная система включенаМеханизм огромной страницы памяти (Huge Page, размер страницы 2M), то вероятность блокировки при обращении родительского процесса за памятью будет сильно увеличена, поэтому механизм Huge Page необходимо отключить на машине Redis. Каждый раз, когда вилка Redis генерирует RDB или перезаписывается AOF, вы можете увидеть в журнале Redis, какой объем памяти был повторно запрошен родительским процессом.

3. Почему AOF не перезаписывает журнал самого AOF?

Перезапись AOF не использует повторно журнал самого AOF:

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

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

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

119 оригинальный контент

перейти к этому макросу:стек будущего