Min free kbytes linux

Настройка ядра Linux для повышения производительности памяти

Контекст

Linux старается оптимизировать использование памяти, занимая свободное место кэшем. Если память никак не используется, то это память, потраченная впустую.

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

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

Причина этого исключительно в том, что оперативная память используется на полную мощность, и других симптомов, кроме случайного эпизодического увеличения задержек, может и не быть. Такая же картина может наблюдаться, если жесткий диск не справляется с чтением и записью. Влияние может быть и на такие компоненты операционной системы как сетевая карта / iptables / ebtables / iproute2 — вместо реальной причины вы видите проблемы в сетевой задержке. В этой статье обсудим это подробнее и посмотрим, как минимизировать воздействие на систему.

Объяснение

В Linux есть несколько видов кэшей:

dirty cache — блоки данных, которые еще не записаны на диск (в файловых системах, поддерживающих кэширование, например, ext4). Этот кэш можно очистить командой sync. Очистка этого кэша может привести к снижению производительности. При обычном режиме работы не стоит этого делать, если только вам не нужно сбросить данные на жесткий диск, например, при аварии.

clean cache — блоки данных, которые для ускорения доступа находятся и на жестком диске и в памяти. Очистка clean cache может привести к снижению производительности, поскольку все данные будут считываться с диска.

inode cache — кэш информации о местоположении inode. Его можно очистить аналогично clean cache, но также с последующим снижением производительности.

slab cache — хранит объекты, выделенные приложениям с помощью malloc, таким образом, что в будущем они могут быть повторно выделены с уже заполненными данными объекта, что ускоряет выделение памяти.

С dirty cache мало что можно сделать, но другие типы кэшей можно очистить. Их очистка может привести к двум результатам. В приложениях, потребляющих много памяти, таких как Aerospike, задержки уменьшатся. Но с другой стороны, замедлится скорость ввода-вывода, так как все данные придется считывать с диска.

Очистка slab cache может привести к временному кратковременному снижению скорости. По этой причине очищать кэш не рекомендуется. Вместо этого, лучше сообщить системе, что определенный объем памяти всегда должен быть свободен и его нельзя занимать кэшем.

При необходимости очистку кэша можно выполнить следующим образом:

Большую часть памяти занимает page cache, поэтому если очищаете кэш, то рекомендуется очищать его (echo 1).

Для исправления проблемы можно установить минимальное количество свободной памяти. Рассмотрим следующий пример:

В этом примере свободно 10 ГБ памяти, ограниченной с использованием параметра minimum free . В случае, если потребуется выделить 5 ГБ памяти, то сделать это можно мгновенно. Для обеспечения 10 ГБ свободной памяти освобождается часть кэша. Выделение памяти будет происходить быстро, а кэш динамически уменьшаться, чтобы 10 ГБ всегда оставались свободными. Распределение памяти будет выглядеть следующим образом:

Точная настройка этих параметров зависит от вашей нагрузки. Для Aerospike, если это позволяет доступный объем памяти, должно быть не менее 1,1 ГБ свободной памяти в min_free_kbytes . Тогда кэш будет в достаточном объеме, оставляя место для размещения приложений.

Настройка выполняется следующим образом:

NUMBER — количество килобайт, которые должны быть свободны в системе.

Чтобы на компьютере со 100 ГБ оставить 3% памяти незанятыми, выполните следующую команду:

Aerospike рекомендует оставлять не менее 1,1 ГБ в min_free_kbytes , т.е. 1153434.

В системе с общим объемом памяти более 37 ГБ следует оставлять не более 3% свободной памяти min_free_kbytes , чтобы ядро не тратило слишком много времени на ненужное восстановление памяти. В таких системах это будет составлять от 1,1 ГБ до 3% от общего объема оперативной памяти.

При установке этого параметра следует проявлять осторожность: слишком маленькое или слишком большое значение может отрицательно сказаться на производительности системы. Слишком низкое значение min_free_kbytes не позволит системе освободить память. Что может привести к зависанию системы или уничтожению процессов через OOM.

Слишком большое значение (5-10% от общей памяти) приведет к тому, что в системе быстро закончится память. Linux для кэширования данных файловой системы использует всю доступную оперативную память. Установка высокого значения min_free_kbytes может привести к тому, что система будет тратить слишком много времени на восстановление памяти.

RedHat рекомендует поддерживать min_free_kbytes на уровне 1-3% от объема памяти в системе. При этом Aerospike рекомендует оставлять не менее 1,1 ГБ, даже если это выше официально рекомендуемого значения.

Также рекомендуется либо уменьшать параметр swappiness до нуля, либо не использовать своп. В любом случае для операций с низкой задержкой использование свопа резко снизит производительность.

Установите значение swappiness в 0 , чтобы уменьшить потенциальную задержку:

Примечания

ВАЖНО: Все изменения, указанные выше, НЕ сохраняются. Они действуют только во время работы машины. Чтобы изменения были постоянными, необходимо внести их в /etc/sysctl.conf .

Добавьте следующие строки:

Как всегда, будьте внимательны при редактировании подобных параметров. Проверьте их на тестовых серверах перед внесением изменений в продакшн-окружение.

Еще один параметр, аналогичный вышеуказанному, — zone_reclaim . К сожалению, этот параметр вызывает агрессивное восстановление и сканирование. Поэтому лучше его отключить. Во всех новых ядрах и дистрибутивах этот параметр по умолчанию выключен.

Для проверки, что zone_reclaim отключен используйте следующую команду:

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

Источник

What is vm.min_free_kbytes and how to tune it?

How vm.min_free_kbytes works

Memory allocations may be needed by the system in order to ensure proper functioning of the system itself. If the kernel allows all memory to be allocated it might struggle when needing memory for regular operations to keep the OS running smoothly. That is why the kernel provides the tunable vm.min_free_kbytes. The tunable will force the kernel’s memory manager to keep at least X amount of free memory. Here is the official definition from the linux kernel documentation: “This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a watermark[WMARK_MIN] value for each lowmem zone in the system. Each lowmem zone gets a number of reserved free pages based proportionally on its size. Some minimal amount of memory is needed to satisfy PF_MEMALLOC allocations; if you set this to lower than 1024KB, your system will become subtly broken, and prone to deadlock under high loads. Setting this too high will OOM your machine instantly.“

Validating vm.min_free_kbytes Works

In order to test that the setting of min_free_kbytes is working as designed, I have created a linux virtual instance with only 3.75 GB of RAM. Use the free command below to analyze the system:

Looking at the free memory utility above using the -m flag to have the values printed in MB. The total memory is 3.5 to 3.75 GB of memory. 121 MB of memory is used, 3.3 GB of memory is free, 251 MB is used by the buffer cache. And 3.3 GB of memory is available.

Now we are going to change the value of vm.min_free_kbytes and see what the impact is on the system memory. We will echo the new value to the proc virtual filesystem to change the kernel parameter value as per below:

You can see that the parameter was changed to 1.5 GB approximately and has taken effect. Now let’s use the free command again to see any changes recognized by the system.

The free memory and the buffer cache are unchanged by the command, but the amount of memory displayed as available has been reduced from 3327 to 1222 MB. Which is an approximate reduction of the change in the parameter to 1.5 GB min free memory.

Now let’s create a 2GB data file and then see what reading that file into the buffer cache does to the values. Here is how to create a 2GB data file in 2 lines of bash script below. The script will generate a 35MB random file using the dd command and then copy it 70 times into a new data_file output:

Let’s read the file and ignore the contents by reading and redirecting the file to /dev/null as per below:

Ok, what has happened to our system memory with this set of maneuvers, let’s check it now:

Analyzing the results above. We still have 1.8 GB of free memory so the kernel has protected a large chunk of memory as reserved because of our min_free_kbytes setting. The buffer cache has used 1691 MB, which is less than the total size of our data file which is 2.3 GB. Apparently the entire data_file could not be stored in cache due to the lack of available memory to use for the buffer cache. We can validate that the entire file is not stored in cache but timing the repeated attempts to read the file. If it was cached, it would take a fraction of a second to read the file. Let’s try it.

The file read took almost 20 seconds which implies its almost certainly not all cached.

As one final validation let’s reduce the vm.min_free_kbytes to allow the page cache to have more room to operate and we can expect to see the cache working and the file read getting much faster.

With the extra memory available for caching the file read time dropped from 20 seconds before to .364 seconds with it all in cache.

I am curious to do another experiment. What happens with malloc calls to allocate memory from a C program in the face of this really high vm.min_free_kbytes setting. Will it fail the malloc? Will the system die? First reset the the vm.min_free_kbytes setting to the really high value to resume our experiments:

Let’s look again at our free memory:

Theoretically we have 1.9 GB free and 515 MB available. Let’s use a stress test program called stress-ng in order to use some memory and see where we fail. We will use the vm tester and try to allocate 1 GB of memory. Since we have only reserved 1.5 GB on a 3.75 GB system, i guess this should work.

Let’s try it again with more workers, we can try 1, 2, 3, 4 workers and at some point it should fail. In my test it passed with 1 and 2 workers but failed with 3 workers.

Let’s reset the vm.min_free_kbytes to a low number and see if that helps us run 3 memory stressors with 1GB each on a 3.75GB system.

This time it ran successfully without error, i tried it two times without problems. So I can conclude there is a behavioral difference of having more memory available for malloc, when the vm.min_free_kbytes value is set to a lower value.

Default setting for vm.min_free_kbytes

The default value for the setting on my system is 67584 which is about 1.8% of RAM on the system or 64 MB. For safety reasons on a heavily thrashed system i would tend to increase it a bit perhaps to 128MB to allow for more reserved free memory, however for average usage the default value seems sensible enough. The official documentation warns about making the value too high. Setting it to 5 or 10% of the system RAM is probably not the intended usage of the setting, and is too high.

Setting vm.min_free_kbytes to survive reboots

In order to ensure the setting can survive reboots and is not restored to the default values when rebooting be sure to make the sysctl setting persistent by by putting the desired new value in the /etc/sysctl.conf file.

Conclusion

We have seen that the vm.min_free_kbytes linux kernel tunable can be modified and can reserve memory on the system in order to ensure the system is more stable especially during heavy usage and heavy memory allocations. The default settings might be a little too low, especially on high memory systems and should be considered to be increased carefully. We have seen that the memory reserved by this tunable prevents the OS cache from using all the memory and also prevents some malloc operations from using all the memory too.

About the author

Linux Wolfman

Linux Wolfman is interested in Operating Systems, File Systems, Databases and Analytics and always watching for new technologies and trends. Reach me by tweeting to @linuxhint and ask for the Wolfman.

Источник

Что такое vm.min_free_kbytes и как его настроить

Главное меню » Linux » Что такое vm.min_free_kbytes и как его настроить

Как работает vm.min_free_kbytes

Выделение памяти может потребоваться системе для обеспечения правильного функционирования самой системы. Если ядро ​​позволяет выделить всю память, оно может столкнуться с трудностями при потребности в памяти для регулярных операций, чтобы обеспечить бесперебойную работу ОС. Вот почему ядро ​​предоставляет настраиваемый vm.min_free_kbytes. Настраиваемый параметр заставит диспетчер памяти ядра сохранить не менее X объема свободной памяти. Вот официальное определение из документации ядра Linux: «Это используется для того, чтобы заставить виртуальную машину Linux сохранять минимальное количество килобайт свободным. ВМ использует это число для вычисления значения водяного знака [WMARK_MIN] для каждой зоны lowmem в системе. Каждая зона lowmem получает количество зарезервированных бесплатных страниц пропорционально ее размеру. Некоторый минимальный объем памяти необходим для распределения PF_MEMALLOC; если вы установите это значение ниже 1024 КБ, ваша система станет незаметно сломанной и склонной к тупиковой ситуации при высоких нагрузках. Установка слишком большого значения мгновенно отключит вашу машину».

Проверка vm.min_free_kbytes Работает

Чтобы проверить, что настройка min_free_kbytes работает так, как задумано, я создал виртуальный экземпляр Linux только с 3,75 ГБ ОЗУ. Используйте бесплатную команду ниже для анализа системы:

Рассмотрим приведенную выше утилиту для свободной памяти с использованием флага -m для вывода значений в МБ. Общий объем памяти составляет от 3,5 до 3,75 ГБ. Используется 121 МБ памяти, свободно 3,3 ГБ, буферный кеш занимает 251 МБ. И доступно 3,3 ГБ памяти.

Теперь мы собираемся изменить значение vm.min_free_kbytes и посмотреть, как это отразится на системной памяти. Мы выведем новое значение в виртуальную файловую систему proc, чтобы изменить значение параметра ядра, как показано ниже:

Видно, что параметр был изменен примерно на 1,5 ГБ и вступил в силу. Теперь давайте снова воспользуемся командой free, чтобы увидеть любые изменения, распознаваемые системой.

Свободная память и буферный кеш не изменяются командой, но объем памяти, отображаемый как доступный, был уменьшен с 3327 до 1222 МБ. Что примерно соответствует уменьшению изменения параметра до 1,5 ГБ мин свободной памяти.

Теперь давайте создадим файл данных размером 2 ГБ, а затем посмотрим, что чтение этого файла в буферный кеш делает со значениями. Вот как создать файл данных размером 2 ГБ в двух строках сценария bash ниже. Сценарий сгенерирует случайный файл размером 35 МБ с помощью команды dd, а затем скопирует его 70 раз в новый вывод data_file :

Давайте прочитаем файл и проигнорируем его содержимое, прочитав и перенаправив файл в /dev/null, как показано ниже:

Хорошо, что случилось с нашей системной памятью с помощью этого набора маневров, давайте сейчас это проверим:

Анализируя результаты выше. У нас все еще есть 1,8 ГБ свободной памяти, поэтому ядро ​​защитило большой кусок памяти как зарезервированный из-за нашей настройки min_free_kbytes. Буферный кеш использовал 1691 МБ, что меньше, чем общий размер нашего файла данных, который составляет 2,3 ГБ. Очевидно, весь файл data_file не может быть сохранен в кеше из-за отсутствия доступной памяти для использования для буферного кеша. Мы можем проверить, что весь файл не хранится в кеше, но рассчитываем время повторных попыток чтения файла. Если он был кэширован, чтение файла заняло бы долю секунды. Давай попробуем.

Чтение файла заняло почти 20 секунд, что означает, что он почти наверняка не кэшируется.

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

С дополнительной памятью, доступной для кэширования, время чтения файла упало с 20 секунд до 0,364 секунды, когда все это было в кеше.

Мне любопытно провести еще один эксперимент. Что происходит с вызовами malloc для выделения памяти из программы на языке C при очень высоком значении vm.min_free_kbytes. Не справится ли он с malloc? Система умрет? Сначала сбросьте параметр vm.min_free_kbytes на действительно высокое значение, чтобы возобновить наши эксперименты:

Теоретически у нас свободно 1,9 ГБ и доступно 515 МБ. Давайте воспользуемся программой стресс-теста под названием stress-ng, чтобы задействовать немного памяти и посмотреть, где мы потерпим неудачу. Мы воспользуемся vm tester и попробуем выделить 1 ГБ памяти. Поскольку мы зарезервировали только 1,5 ГБ в системе 3,75 ГБ, мы думаем, это должно сработать.

Давайте попробуем еще раз с большим количеством воркеров, мы можем попробовать 1, 2, 3, 4 воркера, и в какой-то момент он должен потерпеть неудачу. В нашем тесте он прошел с 1 и 2 рабочими, но не прошел с 3 рабочими.

Давайте сбросим vm.min_free_kbytes на меньшее значение и посмотрим, поможет ли это нам запустить 3 фактора стресса памяти по 1 ГБ каждый в системе 3,75 ГБ.

На этот раз все прошло успешно, без ошибок, мы пробовали два раза без проблем. Таким образом, мы можем сделать вывод, что существует различие в поведении, заключающееся в наличии большего объема памяти для malloc, когда для значения vm.min_free_kbytes установлено более низкое значение.

Настройка по умолчанию для vm.min_free_kbytes

Значение по умолчанию для параметра в моей системе – 67584, что составляет около 1,8% ОЗУ в системе или 64 МБ. По соображениям безопасности на сильно перегруженной системе я бы увеличил его немного, возможно, до 128 МБ, чтобы учесть больше зарезервированной свободной памяти, однако для среднего использования значение по умолчанию кажется достаточно разумным. Официальная документация предупреждает о завышении значения. Установка 5 или 10% системной ОЗУ, вероятно, не является предполагаемым использованием параметра и слишком высока.

Настройка vm.min_free_kbytes, чтобы выжить после перезагрузки

Чтобы гарантировать, что параметр может выдерживать перезагрузку и не восстанавливается до значений по умолчанию при перезагрузке, обязательно сделайте параметр sysctl постоянным, поместив желаемое новое значение в файл /etc/sysctl.conf.

Вывод

Мы видели, что настраиваемый параметр ядра Linux vm.min_free_kbytes может быть изменен и может резервировать память в системе, чтобы обеспечить более стабильную работу системы, особенно при интенсивном использовании и интенсивном распределении памяти. Настройки по умолчанию могут быть слишком низкими, особенно в системах с большим объемом памяти, и их следует тщательно увеличивать. Мы видели, что память, зарезервированная этим параметром, не позволяет кешу ОС использовать всю память, а также предотвращает использование всей памяти некоторыми операциями malloc.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник