На наших серверах у нас есть привычка сбрасывать кеши в полночь.
sync; echo 3 > /proc/sys/vm/drop_caches
Когда я запускаю код, кажется, что он освобождает много оперативной памяти, но действительно ли мне нужно это делать. Разве бесплатная оперативная память не является пустой тратой?
Вы правы на 100%. это не Хорошая практика для освобождения оперативной памяти. Вероятно, это пример системного администрирования культа карго.
Да, очистка кеша освободит оперативную память, но при этом ядро будет искать файлы на диске, а не в кеше, что может вызвать проблемы с производительностью.
Обычно ядро очищает кэш при исчерпании доступной оперативной памяти. Он часто записывает загрязненное содержимое на диск с помощью pdflush.
Причина отказа от таких кешей - это тест производительности диска, и это единственная причина, по которой он существует.
При запуске теста с интенсивным вводом-выводом вы хотите быть уверены, что все различные настройки, которые вы пробуете, действительно выполняют дисковый ввод-вывод, поэтому Linux позволяет вам отбрасывать кеши, а не выполнять полную перезагрузку.
Цитата из документация:
Этот файл не является средством управления ростом различных кешей ядра (inodes, dentries, pagecache и т. Д.). Эти объекты автоматически освобождаются ядром, когда требуется память в другом месте системы.
Использование этого файла может вызвать проблемы с производительностью. Поскольку он отбрасывает кэшированные объекты, воссоздание отброшенных объектов может потребовать значительных затрат ввода-вывода и ЦП, особенно если они интенсивно использовались. По этой причине использование вне среды тестирования или отладки не рекомендуется.
Основная идея здесь, вероятно, не так уж плоха (просто очень наивна и вводит в заблуждение): могут быть кешированные файлы, которые вряд ли будут доступны в ближайшем будущем, например, файлы журналов. Эти "съедают" баран, который в дальнейшем придется освобождать ОС тем или иным способом при необходимости.
В зависимости от ваших настроек подкачки, схемы доступа к файлам, схемы распределения памяти и многих других непредсказуемых вещей, может случиться так, что, когда вы не освободите эти кеши, они позже будут принудительно повторно использованы, что займет немного больше времени, чем выделение памяти из пула неиспользуемой памяти. В худшем случае настройки подкачки в Linux вызовут выгрузку программной памяти, потому что Linux считает, что эти файлы могут быть использованы в ближайшем будущем с большей вероятностью, чем программная память.
В моей среде linux часто ошибается, и в начале работы большинства европейских фондовых бирж (около 09:00 по местному времени) серверы начинают делать то, что они делают только один раз в день, и им нужно менять местами память, которая ранее была заменена из-за записи файлы журналов, их сжатие, копирование и т. д. заполняли кеш до такой степени, что приходилось что-то менять местами.
Но является ли сброс кешей решением этой проблемы? определенно нет. Решением здесь было бы сообщить Linux то, чего он не знает: эти файлы, скорее всего, больше не будут использоваться. Это можно сделать, написав приложение, используя такие вещи, как posix_fadvise() или используя инструмент линии cmd, например vmtouch (который также можно использовать для просмотра вещей, а также файлов кеша).
Таким образом, вы можете удалить из кешей данные, которые больше не нужны, и сохранить то, что должно быть кешировано, потому что, когда вы отбрасываете все кеши, много чего нужно перечитывать с диска. И это в самый неподходящий момент: когда это необходимо; вызывая заметные и часто неприемлемые задержки в работе вашего приложения.
У вас должна быть система, которая отслеживает ваши шаблоны использования памяти (например, если что-то меняет местами), а затем анализирует соответствующим образом и действует соответствующим образом. Решением может быть удаление некоторых больших файлов в конце дня с помощью vtouch; также может быть добавлено больше оперативной памяти, потому что ежедневное пиковое использование сервера - это именно это.
Я видел, что кеши отбрасывания могут быть полезны при запуске множества виртуальных машин. Или что-нибудь еще, что использует большие страницы, например, некоторые серверы баз данных.
Большие страницы в Linux часто нуждаются в дефрагментации ОЗУ, чтобы найти 2 МБ непрерывной физической ОЗУ для размещения на странице. Освобождение всего файлового кеша очень упрощает этот процесс.
Но я согласен с большинством других ответов в том, что обычно нет веской причины сбрасывать кеш файлов каждую ночь.
Возможно, это было введено как способ стабилизации системы, когда не было никого, обладающего навыками или опытом, чтобы действительно найти проблему.
Отбрасывание кешей по существу высвободит некоторые ресурсы, но это имеет побочный эффект, заставляющий систему работать усерднее, чтобы делать то, что она пытается сделать. Если система выполняет подкачку (пытается читать и записывать из раздела подкачки диска быстрее, чем это возможно на самом деле), то периодическое удаление кешей может облегчить симптом, но ничего не делает для лечения причина.
Вы должны определить, что вызывает большое потребление памяти, из-за чего удаление кешей кажется работающим. Это может быть вызвано любым количеством плохо настроенных или просто неправильно используемых серверных процессов. Например, на одном сервере я наблюдал максимальное использование памяти, когда веб-сайт Magento достигал определенного количества посетителей в течение 15-минутного интервала. В конечном итоге это было вызвано тем, что Apache был настроен на одновременное выполнение слишком большого количества процессов. Слишком много процессов, использующих много памяти (Magento иногда - чудовище) = свопинг.
Не думайте, что это что-то необходимое. Проявите инициативу, выясняя, почему она существует, имейте смелость отключить ее, если другие предполагают, что она неправильная, и понаблюдайте за системой - узнайте, в чем реальная проблема, и устраните ее.
Linux / m68k на самом деле имеет ошибку ядра, из-за которой kswapd сходит с ума и съедает 100% ЦП (50%, если есть другая задача, связанная с ЦП, например, autobuilder двоичного пакета Debian - vulgo buildd - уже запущен), что может (большинство времени; не всегда) можно смягчить, выполняя эту конкретную команду каждые несколько часов.
При этом ... ваш сервер, скорее всего, не является системой m68k (Atari, Amiga, Classic Macintosh, VME, Q40 / Q60, Sun3) ;-)
В этом случае человек, вставивший строки, либо следовал каким-то сомнительным или, в лучшем случае, устаревшим советам, либо неправильно понимал, как следует использовать ОЗУ (современное мышление действительно говорит, что «свободная ОЗУ - это потраченная впустую ОЗУ» и предлагает кеширование) , или «обнаружил», что это «исправляет» [sic!] другую проблему в другом месте (и было слишком ленив, чтобы искать правильное решение).
Я могу придумать одну правдоподобную причину для этого в ночной работе cron.
В большой системе может быть полезно периодически отбрасывать кеши, чтобы удалить фрагментацию памяти.
Поддержка прозрачных огромных страниц в ядре выполняет периодическую очистку памяти для объединения маленьких страниц в огромные страницы. В вырожденных условиях это может привести к паузам системы на минуту или две (мой опыт с этим был в RHEL6; надеюсь, это улучшилось). Удаление кешей может позволить очистителю огромных страниц иметь место для работы.
Вы можете возразить, что это хорошая причина отключить прозрачные огромные страницы; OTOH вы можете полагать, что общее улучшение производительности от прозрачных огромных страниц стоит того, и стоит платить цену за потерю ваших кешей один раз в день.
Я придумал еще одну причину, по которой вы хотели бы это сделать, хотя и не в работе cron. Непосредственно перед тем, как система виртуализации перенесет виртуальную машину на новое оборудование, будет очень подходящим временем для этого. Меньше содержимого памяти для копирования на новый хост. В конечном итоге вам, конечно, придется читать из хранилища, но я, вероятно, пошел бы на этот компромисс.
Я не знаю, действительно ли это делает какое-либо программное обеспечение virt.
Одна из причин может заключаться в том, что на сайте выполняется какой-то мониторинг, который проверяет количество свободной оперативной памяти и отправляет предупреждение администраторам, когда объем свободной оперативной памяти падает ниже определенного процента. Если этот инструмент мониторинга достаточно глуп, чтобы не включать кеш в расчет свободной оперативной памяти, он может отправлять ложные предупреждения; Регулярное очищение кеша может подавить эти предупреждения, в то же время позволяя инструменту замечать, когда «реальный» баран становится низким.
Конечно, в такой ситуации реальным решением является изменение инструмента мониторинга, чтобы включить кэш в расчет свободной оперативной памяти; очистка кеша - это всего лишь обходной путь, к тому же плохой, потому что кеш будет быстро пополняться, когда процессы обращаются к диску.
Таким образом, даже если мое предположение верно, очистка кеша - это не то, что имеет смысл, это скорее обходной путь, сделанный кем-то, кто недостаточно компетентен, чтобы решить основную проблему.
Просто чтобы добавить два цента: Система знает Хорошо, что эти страницы памяти являются кешами и будут сбрасывать столько, сколько потребуется, когда приложение запрашивает память.
Соответствующая настройка /proc/sys/vm/swappiness, который сообщает ядру во время нового выделения памяти, что лучше отказаться от кешей памяти или поменять местами «простаивающие» выделенные страницы памяти.
Вопрос с 2014 года, но поскольку проблема существует и по сей день на некоторых скрытых бэкэндах centos 6.8, она может быть кому-то полезна.
https://github.com/zfsonlinux/zfs/issues/1548 описывает проблему с zfs. Там дисковое пространство не освобождается для удаленных файлов, потому что, если nfs используется поверх zfs, индексные дескрипторы файлов не удаляются из кэша инодов ядра.
Цитируя ветку об ошибках, Белендорф написал 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 удаляет кеш страниц, когда приложение запрашивает его:
Но на самом деле не все так просто. Обходной путь:
Пример запуска 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 или в том, что реализация кеша настолько медленная, если памяти много.