важной частью любого операционного окружения является виртуальная память, которая представляет собой совокупность физической памяти (RAM) и областей подкачки (Swap partition/Swap file)
попробуем описать наиболее важные на мой взгляд переменные (ядра 2.6.18 as of RHEL5 и 2.6.26 as of Debian 5), а заодно и прокомментировать, если получится, исходя из собственного опыта.
Замечание: в своих экспериментах я оперирую как правило показаниями утилиты gkrellm и программами top и free. Занятой памятью я считаю по показаниям утилиты free: used RAM = total - free - buffers - cached. Кроме того, судя по моим наблюдением по количеству памяти компьютеры можно условно разбить на 3 категории: мало памяти - 512 и менее мегабайт, достаточно памяти 1-2 гигабайта и много памяти 3 и более гигабайта, в первом случае за счёт более агрессивного механизма управления памяти страдает производительность системы, во втором случае как правило ядру и базовой системе хватает памяти для бОльшей части нужд, кроме того побочного эффекта в виде фрагментации памяти почти не наблюдается (память в большинстве случаев выделяется непрерывной цепочкой блоков)
следующие переменные влияют на поведение ос линукс в отношении управления виртуальной памятью
vm.swappiness -- чем меньше тем более предпочтительнее используется физическая память, ставить в 0 на системах с областью свопа (да и без неё тоже) не рекомендую, при некоторых неочень больших, но довольно постоянных нагрузках (ядра процессоров загружены в среднем на 25% с пичками до 80-90% и провалами до 5% по показаниям Gkrellm) при нуле может ощутимо упасть производительность системы, если памяти 1гб и более, при средней загрузке памяти не более 35% рекомендую выставлять в 5, если занято больше, тогда 15-25
vm.drop_caches
- 0 использовать кэширование inode'ов, списков содержимого каталогов(dentry), страниц памяти
- 1 очистить (и не использовать?) кэш страниц памяти
- 2 очистить (и не использовать?) кэш Inode'ов и dentry
- 3 очистить (и не использовать?) кэш страниц памяти, кэш Inode'ов и dentry
почему "не использовать" с вопросом? - да потому что кэш всё ровно используется, но его рост заметно медленнее чем если если вписать в этот файл 0
vm.overcommit_memory
управляет процессом предоставления (но не использования) объёмов памяти, превышающих физически существующие объёмы (виртуальной) памяти на сервере.
- 0 система эвристически угадывает необходимость предоставления таких объёмов памяти (безумные запросы автоматически идут лесом, рут имеет право на чуть бОльшие объёмы памяти), значение по-умолчанию, позволяет немного снизить своп
- 1 всегда предоставлять, подходит для научных вычислений
- 2 никогда не предоставлять (наиболее безопасный вариант)
Объём адресного пространства для использования системой в данном случае равен количеству свопа плюс некий настраиваемый процент от объёма доступной физической памяти (vm.overcommit_ratio=50, то есть по-умолчанию 50%). В зависимости от количества процентов в большинстве случаев приложения не будут насильно завершаться (SIGTERM) если попытаются использовать уже используемую (занятую) память, однако получат ошибку предоставления памяти.
если памяти достаточно (объём занятой памяти меньше 20% от количества физической памяти), тогда лучше все такие попытки посылать лесом, то есть выбирать значение 2
vfs_cache_pressure
Определяет тенденцию освобождения ядром памяти (возврата памяти системе, пометка её как свободной), занятой кэшем inode'ов и списков объектов в каталогах.
Значение по умолчанию vfs_cache_pressure = 100 позволяет ядру достаточно адекватно возвращать системе память, если значение уменьшить, то ядро будет отдавать предпочтение накоплению этого кэша, если значение увеличить, это сократит кэш.
Как правило этот показатель не меняют, если нет в подобного рода манипуляциях острой необходимости. Возможно его следует увеличить(но не до 200, это может сильно повредить операциям ввода/вывода) на системах с небольшим объёмом памяти (менее 512 мегабайт), которая используется более чем на половину, и на которых в каталогах, к которым происходит частое обращение (за исключением /usr/bin и /usr/lib) содержится не более 1500-2000 файлов. Вероятно, этот параметр следует уменьшить (но не до 0! иначе могут тормозиться дисковые операции по созданию/удалению файлов) если памяти достаточно (более 1 гигабайта), и она загружена менее чем на 40-60% и есть каталоги с большим количеством файлов (более 800), к которым происходит частое обращение. В любом случае эффект от правильной настройки этого параметра не особо велик, а от неправильной существенен.
mmap_min_addr
Указывает количество адресного пространства, которое пользовательский процесс не может mmap'ировать. По умолчанию равен 0. Используется для защиты от т.н. kernel null dereference bugs, чтобы защитить первые несколько страниц памяти пользовательских процессов от kernel null dereference bugs, в результате которых может нечаянно произойти запись в эти страницы памяти. Принято выставлять значение около 65535, этого более чем достаточно для организации надёжной защиты от потенциальных ошибок в ядре.