Память свободна, но все еще свопинг?
Я рисковал бы той памятью, преступник.
Для подтверждения проверить dmesg и /var/log/messages.
Посмотрите специально для oom-killer записи.
Я был в обучении в классе, преподававшем Ted Ts'o и способом, которым он объяснил это мне, когда я спросил, тот же вопрос был похож на это...
По умолчанию ядро резервирует большую часть памяти для кэширования вещей как метаданные файловой системы. Вот почему Ваш "используемый" столбец показывает 905 МБ. Это - общая память, это "используется", подразумевая под программами и кэшем. Фактический объем свободной памяти находится под "бесплатным" столбцом, около "-/+ буферы/кэш", другими словами, 561 МБ. Это - сумма, доступная для использования программами.
Теперь, так как ядру использовали 462 МБ для кэша, оно оставляет 118 МБ абсолютно доступными. Когда в программе говорится ядру, "эй, мне нужны 50 МБ памяти ПРЯМО СЕЙЧАС!", ядро тянет память из этого "свободного" пула. Это делает "свободный" пул на уровне приблизительно 68 МБ, который является слишком маленьким для комфорта, поэтому после того, как та память оттянута, сумма материала, сохраненного в кэше, понижена, и "свободный" пул возвращается.
Но что происходит, если программа является пожирателем ресурсов и говорит, что "Мне нужны 120 МБ памяти ПРЯМО СЕЙЧАС!". У Вас нет так большой "свободной" памяти, таким образом, ядро не может дать ее программе, даже временно, таким образом, ядро роет в подкачку, просто достаточно долго для выделения достаточного количества свободной памяти для предоставления программы, в чем она нуждается, затем достаточно данных кэша выпущено, чтобы позволить "свободной" памяти возвращаться к удобному уровню.
Посредством процесса урегулирования данные в подкачке не становятся освобожденными от подкачки сразу, даже при том, что это - кэшированные данные. Единственное время память подкачки собирается привыкнуть, - то, если что-то запрашивает метаданные (или безотносительно кэшируемой информации), который хранится в том небольшом сегменте подкачки. Таким образом, нет никакого вреда в отъезде его.
Если это беспокоит Вас, можно выполнить 'swapoff' затем 'swapon' для избавлений от него, но это ничего не повреждает.
-
1Большое объяснение! – Antoine Benkemoun 20 April 2010 в 00:00
Управление памятью очень сложно, Понимая, что Ядро Linux O'Reilly предоставляет много подробной информации.
Идея, хотя то, что можно выгрузить память, которая никогда не будет, вероятно, использоваться снова заранее. Можно управлять, как, вероятно, подкачка используется со значением в пределах от от 0 до 100 в /proc/sys/vm/swappiness. Более высокое количество означает более вероятно быть подкачанным.
Прежде чем Вы начнете смешивать с этим, посмотрите, используется ли подкачка активно с путем наблюдения столбцов СИ/таким образом vmstat 3. Если они остаются 0, то там подкачивал продолжение, но нет никакого свопинга, продолжающегося в настоящее время, в этом случае, я рекомендую уехать, это :-) Одна причина состоит в том, что те кэшируемые файлы, настолько свободные, сказали, что Вы о могли бы быть полезными, чтобы иметь в памяти. Не позволяйте бесполезной памяти процесса быть подкачанной, и Вы могли бы пропустить шанс кэшировать некоторые файлы, которые будут полезны для кэширования.
-
1Вы могли бы хотеть попробовать 0 за swappiness, если Вы чувствуете, что могли бы убить кого-то, если необходимо ожидать Firefox для возвращения той памяти каждое утро :-) – Kyle Brandt 19 April 2010 в 22:41
Если у вас есть 95 МБ программных данных, к которым не было доступа в течение часа, что вы бы предпочли:
1) Потратьте 95 МБ физической памяти, содержащей данные, которые никогда, никогда
2) Поменяйте эти 95 МБ на диск и получите дополнительно 95 МБ свободной физической памяти.
Система разумно выбирает вариант 2.
Вы обычно получаете умеренный объем памяти такого типа. во многих системах. Одна из частых причин - программы, которые выделяют память при запуске, а затем ждут запросов, которые никогда не поступают. Во многих системах Linux есть полдюжины серверных программ, которые работают, но фактически никогда не используются.