Какво е vm.min_free_kbytes и как да го настроя?

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

Разпределението на паметта може да е необходимо на системата, за да се гарантира правилното функциониране на самата система. Ако ядрото позволява цялата памет да бъде разпределена, може да се затрудни, когато се нуждае от памет за редовни операции, за да поддържа операционната система безпроблемна. Ето защо ядрото предоставя настройваемите vm.min_free_kbytes. Настройката ще принуди мениджъра на паметта на ядрото да запази поне X количество свободна памет. Ето официалното определение от документация на ядрото на Linux : Това се използва за принуждаване на виртуалната машина на Linux да поддържа минимален брой килобайти свободни. Виртуалната машина използва този номер за изчисляване на воден знак [WMARK_MIN] за всяка зона с ниска памет в системата. Всяка ниска зона получава редица запазени безплатни страници, базирани пропорционално на нейния размер. Необходимо е известно минимално количество памет, за да се задоволят разпределенията на PF_MEMALLOC; ако зададете това на по -ниско от 1024KB, вашата система ще стане фино счупена и склонна към блокиране при големи натоварвания. Задаването на това твърде високо ще OOM вашата машина незабавно.

Валидирането на vm.min_free_kbytes работи

За да проверя дали настройката на min_free_kbytes работи както е проектирано, създадох виртуален екземпляр на Linux само с 3,75 GB RAM. Използвайте безплатната команда по -долу, за да анализирате системата:

Преглеждайки помощната програма за свободна памет по -горе, използвайки флага -m, за да отпечатате стойностите в MB. Общата памет е от 3,5 до 3,75 GB памет. Използва се 121 MB памет, 3.3 GB памет е свободна, 251 MB се използва от буферния кеш. Налични са 3,3 GB памет.

Сега ще променим стойността на vm.min_free_kbytes и ще видим какво е въздействието върху системната памет. Ще повторим новата стойност към виртуалната файлова система proc, за да променим стойността на параметъра на ядрото, както е показано по -долу:

Можете да видите, че параметърът е променен приблизително на 1,5 GB и е влязъл в сила. Сега нека използваме Безплатно команда отново, за да видите всички промени, разпознати от системата.

Свободната памет и буферният кеш се променят от командата, но размерът на паметта се показва като на разположение е намалена от 3327 на 1222 MB. Което е приблизително намаляване на промяната в параметъра до 1,5 GB мин свободна памет.

Сега нека създадем 2GB файл с данни и след това ще видим какво четенето на този файл в буферния кеш прави със стойностите. Ето как да създадете 2GB файл с данни в 2 реда bash скрипт по -долу. Скриптът ще генерира 35MB случаен файл с помощта на командата dd и след това ще го копира 70 пъти в нов файл с данни изход:

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

Добре, какво се е случило с нашата системна памет с този набор от маневри, нека го проверим сега:

Анализирайки горните резултати. Все още имаме 1,8 GB свободна памет, така че ядрото е защитило голяма част от паметта, запазена поради нашата настройка min_free_kbytes. Буферният кеш е използвал 1691 MB, което е по -малко от общия размер на нашия файл с данни, който е 2,3 GB. Явно целият файл с данни не може да се съхранява в кеша поради липсата на налична памет, която да се използва за буферния кеш. Можем да потвърдим, че целият файл не се съхранява в кеша, а определя времето за многократните опити за четене на файла. Ако беше кеширан, ще отнеме част от секундата, за да се прочете файлът. Да пробваме.

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

Като последно валидиране нека намалим vm.min_free_kbytes, за да позволим на кеша на страницата да има повече място за работа и можем да очакваме да видим как кешът работи и четенето на файла става много по -бързо.

С допълнителната памет, налична за кеширане, времето за четене на файла спадна от 20 секунди преди на .364 секунди, като всичко това беше в кеша.

Любопитен съм да направя още един експеримент. Какво се случва с извикванията на malloc за разпределяне на памет от програма на C в лицето на тази наистина висока настройка vm.min_free_kbytes. Ще провали ли malloc? Ще умре ли системата? Първо нулирайте настройката vm.min_free_kbytes на наистина високата стойност, за да възобновите нашите експерименти:

Нека да погледнем отново към нашата свободна памет:

Теоретично имаме 1,9 GB безплатно и 515 MB на разположение. Нека използваме програма за стрес тест, наречена stress-ng, за да използваме малко памет и да видим къде се проваляме. Ще използваме vm tester и ще се опитаме да разпределим 1 GB памет. Тъй като сме запазили само 1,5 GB на 3,75 GB система, предполагам, че това трябва да работи.

Нека опитаме отново с повече работници, можем да опитаме 1, 2, 3, 4 работници и в един момент трябва да се провали. В моя тест той премина с 1 и 2 работници, но не успя с 3 работници.

Нека да нулираме vm.min_free_kbytes на нисък брой и да видим дали това ни помага да стартираме 3 стресори за памет с по 1 GB всеки на 3,75 GB система.

Този път той работи успешно без грешка, опитах го два пъти без проблеми. Така че мога да заключа, че има поведенческа разлика в наличието на повече памет за malloc, когато стойността vm.min_free_kbytes е зададена на по -ниска стойност.

Настройка по подразбиране за vm.min_free_kbytes

Стойността по подразбиране за настройката в моята система е 67584, което е около 1,8% от RAM в системата или 64 MB. От съображения за безопасност на силно разбита система бих имал тенденция да я увелича малко до 128MB, за да позволя по -запазена свободна памет, но за средно използване стойността по подразбиране изглежда достатъчно разумна. Официалната документация предупреждава за завишаване на стойността. Задаването му на 5 или 10% от системната RAM вероятно не е предназначението на настройката и е твърде високо.

Задаване на vm.min_free_kbytes за оцеляване при рестартиране

За да се гарантира, че настройката може да оцелее при рестартиране и не се възстановява до стойностите по подразбиране при рестартиране, не забравяйте да направите настройката sysctl постоянна, като поставите желаната нова стойност във файла /etc/sysctl.conf.

Заключение

Видяхме, че vm.min_free_kbytes ядрото на Linux, което може да се променя, може да бъде модифицирано и да запазва паметта в системата, за да се гарантира, че системата е по -стабилна, особено при тежка употреба и големи разпределения на паметта. Настройките по подразбиране може да са малко прекалено ниски, особено при системи с висока памет и трябва да се имат предвид, че се увеличават внимателно. Видяхме, че запазената от тази настройваема памет пречи на кеша на операционната система да използва цялата памет, а също така предотвратява и някои malloc операции да използват цялата памет.