Почему Linux очищает кэш памяти, когда он почти заполнен?

Вот как выглядит график памяти на VPS с CentOS с 512 МБ ОЗУ и nginx / php-fpm / mysqld, обслуживающих (в основном статический) контент для нескольких тысяч посетителей в день.

График недельной памяти

(это дни на оси х)

Как видите, в кеше и в области буфера это довольно нервно. Кэш-память очищается с нерегулярными интервалами (исключая ответственное задание cron). Обычно, но не всегда, его очищают в точке, где он не может расти больше. Иногда он очищается почти полностью, а иногда только на полпути вниз.

Я пытаюсь понять логику этих чисток. Я ожидал бы, что данные файла будут кэшироваться намного дольше и не увидим никаких других программ, использующих больше памяти, чем обычно, когда очищается кэш памяти.

Это нормальное поведение, или я что-то упустил?

ОБНОВЛЕНИЕ: обновление памяти, кажется, стабилизировало график. По-прежнему видны небольшие капли, но нигде не так много, как до обновления.

После обновления памяти

linux memory cache Redburn
источник

Это контейнер OpenVZ / Virtuozzo или настоящая виртуальная машина, такая как XEN или KVM?

Иордания

Не могу объяснить, что это такое, но у меня есть VPS, который отображает то же поведение. dl.dropbox.com/u/1578899/memory-week.png

EightBitTony

@jordanm Это виртуальная машина на основе Xen.

Redburn

@EightBitTony Спасибо, что поделились. Ваш выглядит немного более «естественным», но я ясно вижу похожую (но, возможно, более предсказуемую) картину падений в кэш-памяти.

Redburn

Я действительно задавался вопросом, отображает ли Munin 2 график / сбор данных достаточно по-разному, чтобы привести к некоторым различиям (более плавный график на вашем графике), но даже мое показывает падение в середине цикла, а не ежедневно. Это странно, конечно.

EightBitTony

Ответы:

Может быть много вещей. Возможно, одна из программ, которые вы запускаете, иногда и на короткое время использует много оперативной памяти. Если на оси x это действительно недели, вам следует выполнить выборку с гораздо более высоким разрешением (например, раз в минуту или даже секунду), чтобы получить больше информации о том, что происходит, что приводит к падению кэша. psи topвывод (включая среднюю нагрузку) в течение этого времени также будет полезен.

Джим Пэрис
источник

Да, я думаю, мы могли бы предположить, что очень короткий, внезапный всплеск использования памяти, который происходит через минуту или около того и не обнаружен Мунином, может привести к сбросу кэша, который, конечно, обнаружен, потому что он сохраняется.

EightBitTony

Заголовок немного сбивает с толку, поскольку он показывает данные за одну неделю, так что это дни недели, а не недели. Что касается частоты опроса: Мунин выбирает данные каждые 5 минут, и я не думаю, что частоту можно изменить. Я использую только nginx, mysql, php-fpm и munin-node. Может, это как-то связано с кешем mysql?

Redburn

У меня была верхняя (отсортированная по использованию памяти) запись выходных данных в файл каждые 5 секунд, затем я проанализировал этот файл и не обнаружил никаких процессов, демонстрирующих какое-либо необычное поведение в тот момент, когда кешированная память внезапно упала. Если процесс не может использовать столько памяти и по-прежнему выходить из этого 5-секундного окна, я не уверен, что это может быть причиной. Но если нет запущенных процессов, что бы это могло быть?

Redburn

Этот поток немного устарел, но быстрое наблюдение за методологией: то, какой вклад процесс вносит в кэш системной памяти, не будет (легко) отражаться сверху , так как очень активный процесс может очень быстро накапливать данные в кеше без собственного выделенная память значительно увеличилась. Например, чтение очень большой файл в маленьких кусках для передачи - в то время как процесс никогда не может использовать больше , чем несколько МБ выделяемых те несколько мегабайта будет постоянно меняться и накапливать ссылки в кэше. Таким образом, в верхнем выводе будет происходить внезапное накопление процессорного времени.

Златовласка

Вы также можете быть заинтересованы в этом: cognitivedissonance.ca/cogware/plog

goldilocks

Одной из возможных причин может быть растущий файл, например, журнал, который либо удаляется, сжимается, либо отправляется куда-либо еще, когда он достигает заданного размера.

В любом случае его размер в кеше, возможно, весь, если в вашей ОС отсутствует нагрузка на память, будет удален из кэша, как только будет удален исходный файл.

jlliagre
источник

Интересная идея, но наиболее активные файлы журналов редко превышают размер файла 25 МБ, прежде чем они будут повернуты, а использование кэша / буфера имеет тенденцию к снижению примерно на 200 МБ.

Redburn