Зачем сбрасывать кеш в Linux?

На наших серверах у нас есть привычка сбрасывать кэши в полночь.

sync; echo 3 > /proc/sys/vm/drop_caches

Когда я запускаю код, кажется, что он освобождает много оперативной памяти, но мне действительно нужно это делать. Разве свободная оперативная память не является пустой тратой?

Вы на 100% правы. Это не хорошая практика , чтобы освободить память. Вероятно, это пример администрирования системы культа грузов.

Да, очистка кеша освободит ОЗУ, но заставляет ядро ​​искать файлы на диске, а не в кеше, что может вызвать проблемы с производительностью.

Обычно ядро ​​очищает кеш при исчерпании доступной оперативной памяти. Он часто записывает грязный контент на диск, используя pdflush.

Причина, по которой такие кеши сбрасываются, заключается в тестировании производительности диска, и это единственная причина, по которой она существует.

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

Цитировать из документации :

Этот файл не является средством управления ростом различных кэшей ядра (inode, dentries, pagecache и т. Д.). Эти объекты автоматически восстанавливаются ядром, когда требуется память в другом месте системы.

Использование этого файла может вызвать проблемы с производительностью. Поскольку он отбрасывает кэшированные объекты, может потребоваться значительное количество операций ввода-вывода и ЦП для воссоздания отброшенных объектов, особенно если они интенсивно используются. Из-за этого использование вне среды тестирования или отладки не рекомендуется.

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

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

В моей среде linux часто ошибается, и в начале работы большинства европейских фондовых бирж (около 09:00 по местному времени) серверы начинают делать то, что они делают, только один раз в день, требуя замены в памяти, которая ранее была заменена из-за записи лог-файлы, сжимая их, копируя их и т. д., заполняли кэш до такой степени, что все должно было быть заменено.

Но удаляет ли кэши решение этой проблемы? определенно нет. В этом случае решение заключается в том, чтобы сообщить linux то, чего он не знает: эти файлы, скорее всего, больше не будут использоваться. Это может быть сделано пишущим приложением, использующим такие вещи, как posix_fadvise()или с помощью инструмента командной строки cmd vmtouch(который также может использоваться для просмотра вещей, а также файлов кэша).

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

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

Я видел, что кэши сброса полезны при запуске группы виртуальных машин. Или что-нибудь еще, что использует большие страницы, такие как некоторые серверы баз данных.

Большие страницы в Linux часто требуют дефрагментации ОЗУ, чтобы найти 2 МБ непрерывной физической ОЗУ для размещения на странице. Освобождение всего файлового кэша делает этот процесс очень простым.

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

Вполне возможно, что это было установлено как способ стабилизации системы, когда не было никого, кто обладал бы навыками или опытом, чтобы действительно найти проблему.

Освобождение ресурсов

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

Что съедает память?

Вы должны определить, что приводит к большому потреблению памяти, из-за которого сбрасывание кэшей работает. Это может быть вызвано любым количеством плохо сконфигурированных или просто неправильно используемых серверных процессов. Например, на одном сервере я наблюдал максимальное использование памяти, когда веб-сайт Magento достиг определенного количества посетителей в течение 15-минутного интервала. Это вызвано тем, что Apache настроен на одновременное выполнение слишком большого количества процессов. Слишком много процессов, использующих много памяти (иногда Magento - зверь) = обмен.

Нижняя линия

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

В Linux / m68k на самом деле есть ошибка в ядре, из-за которой kswapd сходит с ума и поглощает 100% ЦП (50%, если есть какая-то другая задача, связанная с ЦП, например, автоматический сборщик двоичных пакетов Debian - vulgo buildd - уже запущен), который может (большинство времени, не всегда) можно смягчить, выполнив эту конкретную команду каждые несколько часов.

При этом ... ваш сервер, скорее всего, не является системой m68k (Atari, Amiga, Classic Macintosh, VME, Q40 / Q60, Sun3) ;-)

В этом случае человек, который вставил эти строки, либо последовал сомнительному, либо, в лучшем случае, устаревшему совету, либо получил представление о том, как следует неправильно использовать оперативную память (современное мышление действительно говорит: «свободная память - это потеря памяти» и предлагает кеширование). или «обнаружил», что это «исправляет» [sic!] другую проблему в другом месте (и было слишком лениво, чтобы искать правильное решение).

Одной из причин может быть то, что на сайте запущен какой-то мониторинг, который проверяет количество свободной оперативной памяти и отправляет предупреждение администраторам, когда объем свободной оперативной памяти падает ниже определенного процента. Если этот инструмент мониторинга достаточно глуп, чтобы не включать кеш в расчет свободного оперативного памяти, он может отправлять ложные предупреждения; регулярное очищение кеша может подавить эти предупреждения, в то же время позволяя инструменту замечать, когда «реальный» баран становится низким.

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

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

Я могу придумать одну правдоподобную причину сделать это в ночной работе cron.

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

Поддержка прозрачных огромных страниц в ядре периодически выполняет загрузку памяти для объединения маленьких страниц в огромные. В вырожденных условиях это может привести к системным паузам на одну или две минуты (мой опыт с этим был в RHEL6; надеюсь, он улучшился). Удаление кешей может дать огромной странице подметать пространство для работы.

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

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

Я не знаю, делает ли это какое-либо программное обеспечение в действительности.

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

Соответствующим параметром является то /proc/sys/vm/swappiness, что ядро ​​при новом выделении памяти сообщает ядру о необходимости отбрасывать кэш-память или менять местами выделенные страницы памяти.

Вопрос с 2014 года, но поскольку проблема существует и по сей день на некоторых скрытых бэкэндах Centos 6.8, она все еще может быть полезна для кого-то.

https://github.com/zfsonlinux/zfs/issues/1548 описывает проблему с zfs. Там дисковое пространство не освобождается для удаленных файлов, потому что, если nfs используется поверх zfs, иноды файла не удаляются из кэша inode ядра.

Цитировать из ветки об ошибках, Беленендорф, 6 ​​января 2015 г.

Текущее предположение состоит в том, что по какой-то причине сервер NFS хранит кэшированную версию дескриптора файла. Пока NFS-сервер не удалит этот дескриптор файла, ZFS не сможет отсоединить этот файл. Некоторое легкое тестирование показало, что удаление кэшей на сервере приведет к удалению этой ссылки (подобно дескриптору файла NFS), после чего пространство будет освобождено правильно. Давление памяти также может привести к его падению.

то есть ночной эхо 3> / proc / sys / vm / drop_caches - самое простое исправление для этой ошибки, если вы не хотите иметь время простоя для реструктуризации ваших zfs.

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

Это может иметь смысл в системах NUMA (с неоднородным доступом к памяти), где, как правило, каждый ЦП (сокет) может осуществлять прозрачный доступ ко всей памяти, но к его собственной памяти можно обращаться быстрее, чем к памяти другого сокета, в сочетании с параллельными приложениями HPC.

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

Однако в системе HPC было бы разумнее очищать кэш перед началом нового пользовательского задания, а не в определенное время с помощью cron.

Для непараллельных приложений эта проблема вряд ли возникнет.

Когда кэш вашей страницы довольно большой (намного больше, чем текущее использование свопинга), а своп и своп происходят по очереди, это когда вам нужно удалить кеш. Я видел случаи, когда использование памяти увеличивалось на одном из моих серверов баз данных MariaDB под управлением Ubuntu 16.04LTS, и Linux просто решил увеличить использование подкачки вместо удаления неиспользуемых кэшей страниц. Прозрачные огромные страницы уже отключены в моей системе, потому что TokuDB требовал, чтобы это было отключено. В любом случае, возможно, это не ошибка, но linux, все еще ведущий себя таким образом, меня озадачивает. Различные источники утверждали, что Linux удалит кеш страниц, когда приложение запросит это:

• https://www.linuxatemyram.com/
• https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

Но реальность не так проста. Обходной путь:

1. Периодически выполнять сброс кеша
2. Выполняйте удаление кэша, когда это необходимо (следите за использованием vmstat 1 для выгрузки операций)
3. Посоветуйте linux удалить определенные файлы из кэша (например, файлы журнала apache) с помощью таких утилит, как dd или python-fadvise. См. Https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache

Пример выполнения dd:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

Пример python-fadvise:

pyadvise -d /var/log/apache2/access_log.1

У меня есть настольный компьютер с 16 ГБ оперативной памяти, работающей на ядре PAE. Через час или два производительность диска резко снижается, пока я не сбрасываю кеш, поэтому я просто помещаю его в cron. Я не знаю, является ли это проблемой с ядром PAE или с такой медленной реализацией кэша, если есть много памяти.