У меня есть сервер с Dual Nehalem Quad Core Xeon 5520 и 12 ГБ оперативной памяти DDR3. Среднее использование памяти сервером составляет всего около 10-15%, но используемый Swap показывает 10% +. Это нормально или может быть что-то не так, что вызывает это? У меня создалось впечатление, что Swap использовался только в том случае, если не хватало памяти.
Я использую Apache / 2.0.63 на CentOS 5.3.
В этом нет ничего плохого. Ядро будет постепенно загружаться в виртуальную память. Это также может произойти, если на вашем сервере наблюдаются «всплески» активности, а имеющаяся у вас в настоящее время память быстро заполняется. Из-за давления на систему памяти происходит выгрузка страниц до тех пор, пока давление не снизится до заданного значения (которое вы можете проверить в / proc / sys / vm). Даже в довольно простаивающей системе я наблюдал постепенные выгрузки страниц с течением времени. Так что, если своп не достаточно активен (много ошибок страниц, приводящих к подкачке страниц), я бы не стал беспокоиться об этом.
Если вы действительно так обеспокоены, вы всегда можете выключить, а затем включить замену. Это заставит эти подкачанные страницы вернуться в память. Я не рекомендую это делать, но вы можете, если хотите. Просто убедитесь, что у вас достаточно свободной памяти, прежде чем делать это.
Не беспокойтесь об этом - поменяйте местами воля использоваться, если ядро считает, что доступ к данным не будет достаточным, чтобы гарантировать их хранение в физической памяти.
Если вы хотите отслеживать использование "плохих" свопов, вам лучше контролировать ставка при котором происходит чтение и запись подкачки, а не просто используется он вообще или нет.
Например...
# vmstat 3
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 19528 45324 19348 240132 50 17 93 26 30 30 0 1 98 1
0 0 19528 45324 19348 240156 0 0 0 3 9 23 0 0 100 0
0 0 19528 45324 19352 240156 0 0 0 9 9 25 0 0 100 0
0 0 19528 45324 19352 240156 0 0 0 0 5 17 0 0 100 0
Первый отчет сообщает вам, каковы состояния (средние) с момента первого включения машины, в остальных (в приведенном выше случае) вы должны увидеть средние значения за 3 секунды.
Обратите внимание на si и so поля в основном нулевые - это то, что вас интересует.
(опубликовано как ответ, так как он слишком длинный, чтобы добавить в качестве дополнительного комментария к ответу Эйвери Пейн)
Кроме того, если своп использовался в течение пикового периода, который с тех пор прошел, вы можете обнаружить, что большая часть данных в свопе также в настоящее время находится в ОЗУ. Если Linux считывает страницы обратно из подкачки в ОЗУ, он не освобождает пространство подкачки немедленно, если оно не требуется для дополнительных данных, таким образом, если ему нужно поменять страницы обратно (и он знает, что данные в них не изменились. ) на самом деле не нужно записывать страницы на диск, поскольку они уже там.
Подробнее см. / Proc / meminfo. Сейчас на моем маленьком сервере:
olm:/proc# free -m
total used free shared buffers cached
Mem: 1487 1457 30 0 15 1094
-/+ buffers/cache: 347 1139
Swap: 980 112 868
olm:/proc# cat meminfo
MemTotal: 1523572 kB
MemFree: 30688 kB
Buffers: 15724 kB
Cached: 1120884 kB
SwapCached: 67868 kB
SwapTotal: 1004052 kB
SwapFree: 888928 kB
Итак, здесь ~ 66 МБ из 112 МБ выделенного пространства подкачки в настоящее время также присутствует в ОЗУ. Нет смысла удалять эти 66 Мб из свопа, так как пространство для других целей не требуется (есть много полностью свободного места для свопа). Если подкачка заполнится, эти страницы будут перераспределены, если страницы изменятся в ОЗУ, они будут помечены как грязные и свободные для перераспределения, но если их нужно переставить обратно, ядро может сохранить кучу операций записи на диск.
Если я принудительно очищаю кеши и буферы диска с помощью
sync; echo 3 > /proc/sys/vm/drop_caches
результат остается прежним:
olm:/proc# free -m
total used free shared buffers cached
Mem: 1487 1278 209 0 0 979
-/+ buffers/cache: 298 1189
Swap: 980 112 868
olm:/proc# cat meminfo
MemTotal: 1523572 kB
MemFree: 212320 kB
Buffers: 652 kB
Cached: 1005732 kB
SwapCached: 67868 kB
SwapTotal: 1004052 kB
SwapFree: 888928 kB
«Кэшированное» чтение оставалось высоким после запроса на очистку дисковых кешей, поскольку это также учитывает память, выделенную виртуальным машинам VMWare, из-за способа, которым она выделяется. Чтение SwapCached не изменилось, поскольку нет смысла копировать страницы обратно в ОЗУ только потому, что ОЗУ теперь свободно - они могут никогда не понадобиться до того, как ОЗУ снова будет выделено для чего-то еще, поэтому эти чтения будут потрачены впустую.
Приведенная выше ситуация немного отличается от вашей в том, что на этой машине почти всегда вся оперативная память выделена для чего-то (виртуальные машины, другие процессы, кеш ввода-вывода + буферы), но в зависимости от истории загрузки вашего компьютера с момента последней загрузки вполне вероятно, что часть страниц в выделенном пространстве в области подкачки также находится в ОЗУ.
Это нормально, поскольку это может быть вызвано пиками использования, или ядро может решить, что некоторые элементы помещены в своп, потому что разумнее использовать ОЗУ для чего-то другого (кеш страницы).
Так как ответы на другие вопросы указал sysctl vm.swappiness может быть вам интересно, все же избегайте этого.