Почему 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