На моем сервере 8 ГБ ОЗУ и 8 ГБ настроено для файла подкачки. У меня запущены приложения, интенсивно использующие память. Эти приложения имеют пиковую нагрузку, во время которой мы обнаруживаем увеличение использования свопа. Используется примерно 1 ГБ свопа.
У меня есть еще один сервер с 4 ГБ ОЗУ и 8 ГБ подкачки и аналогичные приложения, интенсивно использующие память. Но здесь использование свопа очень незначительно. Около 100 МБ.
Мне было интересно, что это за точный условия или грубая формула на основе которого Linux выполнит подкачку памяти процесса в ОЗУ в файл подкачки. Я знаю это по фактору подкачки. На чем еще он основан? Размер файла подкачки? Любые указатели на внутреннюю документацию / исходный код ядра Linux, объясняющие это, будут хороши.
Подсистема виртуальной машины в ядре Linux - очень сложный зверь, ядро использует эвристику и алгоритмы, чтобы определить, какие страницы нужно менять местами и когда это делать. Я не думаю, что существует простая формула, которая могла бы описать, как и когда страницы помещаются на диск. Может быть, эта статья LWN будет вам полезна:
Расширяя ответ pfo, поставщик также может предварительно настроить свое развернутое ядро (а) для обработки подкачки определенным образом. В системе Red Hat вы можете настроить большую часть этого в /etc/sysctl.conf - Google up такие настройки, как:
vm.swappiness
vm.vfs_cache_pressure
Тщательно настроив подкачку системы в соответствии с конкретными потребностями вашего приложения, вы сможете уменьшить использование подкачки на этой машине объемом 8 ГБ. У меня есть примечание в моих файлах, в котором для vm.swappiness говорится, что «использование памяти подкачки по умолчанию в Kernel 2.6.xx установлено на 60%», но я не сохранил ссылку там, где я это читал, так что воспринимайте это с зерном соли. :)
Как вы, наверное, знаете, ядро linux использует как можно больше памяти для кэширования вещей. Вот почему, судя по верхней строке, вывод free выглядит так, будто мне почти не хватает памяти:
$ free -m
total used free shared buffers cached
Mem: 3168 2963 205 0 155 1263
-/+ buffers/cache: 1543 1624
Swap: 494 86 407
но важная часть - это объем ОЗУ, который буферы и кеш не используют
-/+ buffers/cache: 1543 1624
Тем не менее, в этом примере используется вся память, кроме 205 МБ, даже если это кэш. Как мне объяснили (или, по крайней мере, как я это понял), если программа внезапно запрашивает> 205 МБ памяти, этот фрагмент выходит из подкачки, так что процесс может иметь фрагмент памяти, тогда он выходит из swap, как только появится возможность освободить память, используемую кешем.
Как уже упоминалось, лежащие в основе механизмы сложны и выходят далеко за рамки моего понимания. Я задал Теду Тсо почти такой же вопрос на уроке, который он преподавал в LISA, и дал вам, по сути, тот же ответ, который он дал мне, или, по крайней мере, в том виде, в котором я его понял.
Между прочим, я подозреваю, что память, «используемая» в свопинге, на данный момент фактически ничем не используется, но просто еще не освобождена.
Загляните в эту самую проблему на производственных серверах приложений JBoss на AWS.
Я бы разделил sysctl -a на обе системы.
1) Для серверов установите для vm.swappiness значение около 0. При этом предпочтительнее хранить данные в памяти.
2) Включите небольшой файл подкачки на всех серверах, чтобы вы могли отслеживать фактическую загрузку памяти. (Проверить использованный своп%).
3) Мониторинг ошибок страницы (nFLT) с помощью Cacti или подобного.
4) Проверьте ulimits.
5) Настройтесь на основе измеряемой производительности приложения.