Подкачка должна использоваться как это?
tail - Доступный в большинстве систем Linux/Unix позволяет Вам просмотреть последние строки файла (или заключительная часть). tail -f позволяет Вам просматривать новые строки, добавленные к файлу, как они появляются.
Для Windows I как BareTail.
Нет ничего неправильно с этим. Ядро будет разбивать на страницы в virutal память постепенно со временем. Это может также произойти, если Ваш сервер имеет действие "скачки" и память, Вы в настоящее время имеете свободный, быстро заполняется. Давление на систему памяти заставляет страницу-outs происходить, пока давление не снижено к заданной точке (который можно исследовать в/proc/sys/vm). Даже в довольно неактивной системе, я видел постепенную страницу-outs со временем. Так, если подкачка не довольно активна (много отсутствий страницы, приводящих к действию подкачки страниц), я не волновался бы об этом.
Если Вы действительно, который коснулся, можно всегда выключать свопинг, то на. Это сдержит те подкачанные страницы в память. Я не рекомендую делать это, но Вы можете, если Вы хотите. Просто убедитесь, что у Вас есть достаточная свободная память, прежде чем Вы сделаете это.
Вы не должны волноваться об этом - подкачка будет использоваться, если ядро будет считать, что данные не будут полученными доступ достаточно для гарантирования наличия его в физической памяти.
Если требуется контролировать "плохое" использование подкачки, Вы - более обеспеченный контроль уровня, на котором чтения подкачки и записи происходят, не просто, если это используется вообще или нет.
Например...
# 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 поля являются главным образом нулем - это - то, чем Вы интересуетесь.
Это прекрасно, как уже говорилось скачки использования могут вызвать это, или ядро может решить, что некоторые объекты помещаются в подкачку, потому что более умно использовать RAM для чего-то еще (кэш страницы).
Как отвечает на другие вопросы, на которые указывают sysctl vm.swappiness может представлять интерес для Вас, действительно избегают этого.
(отправленный как ответ, поскольку это стало слишком длинным для добавления как дополнительный комментарий к ответу Avery Payne),
Кроме того, если подкачка использовалась в пиковый период, который с тех пор передал Вас, может найти, что большинство данных в подкачке находится также в настоящее время в RAM. Если страницы чтений Linux назад от загружают до RAM, она сразу не освобождает область подкачки, если ей не нужен он для большего количества данных, тот путь, если она должна выгрузить страницы назад (и она знает, что данные в них не изменились) они не должны на самом деле писать страницы в диск, как они уже там.
См./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
Так здесь ~66Mb 112 МБ выделенной области подкачки также в настоящее время присутствует в RAM. Нет никакого смысла этого удаляющий это 66 МБ из подкачки, поскольку нет никакого спроса на пространство для другого использования (существует много абсолютно бесплатной области подкачки). Если подкачка станет полной, то те страницы будут перераспределены, если страницы изменятся в RAM, то они будут отмечены как грязные и свободные быть перераспределенными, но если они должны быть выгружены назад, ядро может сохранить себя набор записей на диск.
Если я вынуждаю дисковые кэши и буферы быть очищенными с
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 VMs также из-за пути, который выделяется. Чтение SwapCached не изменилось, поскольку нет никакого смысла, копируя страницы назад в RAM просто, потому что RAM теперь свободна - они никогда не могли бы быть необходимы, прежде чем RAM выделяется для чего-то еще снова, таким образом, те чтения были бы потрачены впустую.
Ситуация выше немного отличается к Вашему в той этой машине, в значительной степени всегда имеет всю ее RAM, выделенную чему-то (VMs, другие процессы, ввод-вывод cache+buffers), но в зависимости от истории загрузки Вашей машины начиная с последней начальной загрузки не маловероятно, что блок страниц в выделенном месте в Вашей области подкачки находится так же также в RAM.