Vm/min_free_kbytes - Зачем хранить минимальную зарезервированную память?

В соответствии с этой статьей :

/proc/sys/vm/min_free_kbytes: Это контролирует объем свободной памяти для использования с помощью специальных резервов, включая "атомные" распределения (те, которые не могут ждать возврата)

Мой вопрос в том, что это означает "те, которые не могут ждать возврата"? Другими словами, я хотел бы понять, почему необходимо сообщить системе, что она всегда хранит определенный минимальный объем свободной памяти и при каких обстоятельствах будет использоваться эта память? [Он должен быть использован кем-то; не вижу необходимости в противном случае]

Мой второй вопрос: устанавливает ли эта память что-то большее, чем 4 МБ (в моей системе), приводит к лучшей производительности? У нас есть сервер, который изредка демонстрирует очень низкую производительность оболочки (например, ls -l занимает 10-15 секунд для выполнения), когда некоторые процессы начинают работать, и если установка этого номера на что-то более высокое приведет к лучшей производительности оболочки?

Ответ 1

(ссылка мертва, теперь выглядит здесь)

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

См. Linux-MM для более подробного объяснения, но здесь кратко описан процесс распределения памяти:

_alloc_pages сначала выполняет итерацию по каждой области памяти, ища первую, содержащую допустимые бесплатные страницы.

_alloc_pages затем просыпает задачу kswapd [..to..] в пулы резервной памяти, поддерживаемые для каждой зоны.

Если распределение памяти по-прежнему не выполняется, страницы _alloc либо откажутся от [..] . В этом процессе _alloc_pages выполняет cond_resched(), что может вызвать спящий режим, поэтому этой ветке запрещено распределять GFP_ATOMIC.

min_free_kbytes вряд ли поможет многим с описанным "ls -l занимает 10-15 секунд для выполнения"; что, скорее всего, вызвано общим давлением памяти и заменой, а не потерей зоны. Для параметра min_free_kbytes требуется только достаточное количество бесплатных страниц для обработки мгновенных запросов. Как только нормальная работа будет возобновлена, процесс swapper можно запустить, чтобы перебалансировать зоны памяти. Единственный раз, когда мне приходилось увеличивать min_free_kbytes, это после включения jumbo-кадров на сетевой карте, которая не поддерживала рассеяние dma.

Чтобы немного расширить свой второй вопрос, у вас будут лучшие результаты настройки vm.swappiness и грязных отношений, упомянутых в связанной статье. Однако имейте в виду, что оптимизация производительности "ls -l" может привести к замедлению других процессов. Никогда не оптимизируйте для non-primary usecase.

Ответ 2

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

"wait for reclaim", в вашем вопросе, относится к процессу восстановления этой кэш-памяти, которая "не используется", так что она может быть выделена процессу. Это должно быть прозрачным, но в реальном мире есть много процессов, которые не ждут появления этой памяти. Java - хороший пример, особенно там, где установлен большой размер минимальной кучи. Процесс пытается выделить память, и если он не мгновенно доступен в одном большом смежном (атомном?) Фрагменте, процесс умирает.

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

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

Ответ 3

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

Если память заполнена, запускается процесс прерывания (управления памятью), чтобы обменять часть памяти на диск, чтобы освободить часть памяти для использования обычными процессами. Но если vm.min_free_kbytes слишком мал для запуска, он блокирует систему. Это связано с тем, что этот процесс прерывания должен сначала запускаться, чтобы освободить память, чтобы другие могли работать, но затем он застрял, потому что ему не хватает зарезервированной памяти vm.min_free_kbytes для выполнения своей задачи, что приводит к взаимоблокировке.

Также см:

https://www.linbit.com/en/kernel-min_free_kbytes/ и
https://askubuntu.com/info/41778/computer-freezing-on-almost-full-ram-possbly-disk-cache-problem (где процесс управления памятью имеет так мало памяти, чтобы работать с ним, требуется так много времени для подкачки понемногу это похоже на замерзание.)