Почему кэши отбрасывания в Linux?
Я полагаю, что в прошлый раз реализовал что-то вроде этого, что я использовал подсети IP вместо AD групп, использующих squidguard. Я полагаю, что группы не должны быть проблемой, но будут легче, если Вы могли бы отправить свой squid.conf и пример названий группы и каких-либо сообщений об ошибках, Вы видите?
Вы на 100% правы. Это не хорошая практика для освобождения оперативной памяти. Вероятно, это пример системного администрирования культа карго.
Просто чтобы добавить мои два цента: система очень хорошо знает , что эти страницы памяти являются кешами, и будут терять столько, сколько необходим, когда приложение запрашивает память.
Соответствующий параметр - / proc / sys / vm / swappiness , который сообщает ядру во время нового выделения памяти, что лучше отбрасывать кеши памяти или переключаться в состояние ожидания. выделенные страницы памяти.
One reason might be the site is running some kind of monitoring, that checks the amount of free ram and sends a warning to administrators when free ram drops below a certain percentage. If that monitoring tool is dumb enough not to include cache in the free ram calculation, it might send false warnings; regularily emptying the cache could suppress these warnings while still allowing the tool to notice when "real" ram gets low.
Of course, in this kind of situation, the real solution is to modify the monitoring tool to include cache in the free ram calculation; cleaning the cache is just a workaround, and a bad one as well, because the cache will refill quickly when processes access the disk.
So even if my assumption is true, the cache-cleaning is not something that makes sense, it's rather a workaround by someone who isn't competent enough to fix the primary problem.
Причина отбрасывания кешей подобным образом заключается в тестировании производительности диска, и это единственная причина, по которой он существует.
При выполнении теста с интенсивным вводом-выводом вы хотите быть уверены, что различные настройки, которые вы пробуете, фактически выполняют дисковый ввод-вывод, поэтому Linux позволяет вам удалять кеши, а не выполнять полную перезагрузку.
Этот файл не средство для контроля роста различных ядер кеши (inodes, dentries, pagecache и т. д.). Эти объекты автоматически восстанавливается ядром, когда память требуется в другом месте в системе.
Использование этого файла может вызвать проблемы с производительностью. Поскольку он отбрасывает кэшированные объекты, это может потребовать значительных затрат ввода-вывода и ЦП для воссоздайте упавшие предметы, особенно если они интенсивно использовались. Из-за этого использование вне среды тестирования или отладки является не рекомендуется.
Возможно, это было сделано как способ стабилизации когда не было никого, обладающего навыками или опытом, чтобы на самом деле найти проблему.
Освобождение ресурсов
Удаление кешей по существу освободит некоторые ресурсы, но это имеет побочный эффект, заставляя систему работать усерднее, чтобы делать то, что это пытается сделать. Если система выполняет подкачку (пытается читать и записывать из раздела подкачки диска быстрее, чем это возможно на самом деле), то периодическое удаление кешей может облегчить симптом , но не поможет устранить причину .
Что поглощает память?
Вы должны определить, что является причиной большого потребления памяти, из-за чего удаление кешей кажется работающим. Это может быть вызвано любым количеством плохо настроенных или просто неправильно используемых серверных процессов. Например, на одном сервере я наблюдал максимальное использование памяти, когда веб-сайт Magento достигал определенного количества посетителей в течение 15-минутного интервала. В конечном итоге это было вызвано тем, что Apache был настроен на одновременное выполнение слишком большого количества процессов. Слишком много процессов, использующих много памяти (Magento иногда - чудовище) = свопинг.
Bottom Line
Не думайте, что это что-то необходимое. Проявите инициативу, выясняя, почему она существует, имейте смелость отключить ее, если другие предполагают, что она неправильная, и понаблюдайте за системой - узнайте, в чем реальная проблема, и устраните ее.
Да, очистка кеша освободит оперативную память, но заставляет ядро искать файлы на диске, а не в кеше, что может вызвать проблемы с производительностью.
Обычно ядро очищает кэш, когда доступная оперативная память исчерпана. Он часто записывает загрязненное содержимое на диск с помощью pdflush.
Linux/m68k actually has a kernel bug which causes kswapd to go crazy and eat up 100% CPU (50% if there’s some other CPU-bound task, like a Debian binary package autobuilder – vulgo buildd – running already), which can (most of the time; not always) be mitigated by running this particular command every few hours.
That being said… your server is most likely not an m68k (Atari, Amiga, Classic Macintosh, VME, Q40/Q60, Sun3) system ;-)
In this case, the person who put in the lines either followed some questionable or, at best, outdated advice, or got the idea about how RAM should be used wrong (modern thinking indeed says “free RAM is RAM wasted” and suggests caching), or “discovered” that this “fixes”[sic!] another problem elsewhere (and was too lazy to search for a proper fix).
Основная идея здесь, вероятно, не так уж плоха (просто очень наивна и вводит в заблуждение): могут быть кэшированные файлы, к которым вряд ли будет доступ в ближайшем будущем, например, файлы журналов. Эти "съедают" баран, который в дальнейшем придется освобождать ОС тем или иным способом при необходимости.
В зависимости от ваших настроек подкачки, схемы доступа к файлам, схемы распределения памяти и многих других непредсказуемых вещей, может случиться так, что, если вы не освободите эти кеши, они позже будут принудительно повторно использованы, что займет немного времени. больше времени, чем выделение памяти из пула неиспользуемой памяти. В худшем случае настройки подкачки в Linux вызовут выгрузку программной памяти, потому что Linux считает, что эти файлы могут быть использованы в ближайшем будущем с большей вероятностью, чем программная память.
В моей среде linux часто ошибается, и в начале работы большинства европейских фондовых бирж (около 09:00 по местному времени) серверы начинают делать то, что они делают только один раз в день, при этом требуется подкачка памяти, которая ранее была заменена из-за того, что запись файлов журнала, их сжатие, копирование и т. д. приводило к заполнению кеша до такой степени, что все приходилось выгружать.
Но является ли удаление кешей решением этой проблемы? определенно нет. Решением здесь было бы сообщить Linux то, чего он не знает: эти файлы, скорее всего, больше не будут использоваться. Это можно сделать, написав приложение, используя такие вещи, как posix_fadvise () или используя инструмент командной строки, такой как vmtouch (который также может использоваться для просмотра вещей, а также файлов кеша) .
Таким образом, вы можете удалить данные, которые больше не нужны, из кешей и сохранить то, что должно быть кэшировано, потому что, когда вы отбрасываете все кеши, многие данные приходится перечитывать с диска. И это в самый неподходящий момент: когда это необходимо; вызывая задержки в вашем приложении, которые являются заметными и часто неприемлемыми.
Вы должны иметь систему, которая отслеживает ваши шаблоны использования памяти (например, если что-то меняет местами), а затем анализирует их и действует соответствующим образом. Решением может быть удаление некоторых больших файлов в конце дня с помощью vtouch; также может быть добавлено больше оперативной памяти, потому что суточная пиковая загрузка сервера - это именно это.
И это в самый неподходящий момент: когда это необходимо; вызывая задержки в вашем приложении, которые являются заметными и часто неприемлемыми.Вы должны иметь систему, которая отслеживает ваши шаблоны использования памяти (например, если что-то меняет местами), а затем анализирует их и действует соответствующим образом. Решением может быть удаление некоторых больших файлов в конце дня с помощью vtouch; также может быть добавлено больше оперативной памяти, потому что суточная пиковая загрузка сервера - это именно это.
И это в самый неподходящий момент: когда это необходимо; вызывая задержки в вашем приложении, которые являются заметными и часто неприемлемыми.Вы должны иметь систему, которая отслеживает ваши шаблоны использования памяти (например, если что-то меняет местами), а затем анализирует их и действует соответствующим образом. Решением может быть удаление некоторых больших файлов в конце дня с помощью vtouch; также может быть добавлено больше оперативной памяти, потому что суточная пиковая загрузка сервера - это именно это.
У меня есть настольный компьютер с 16 ГБ ОЗУ, работающий на ядре PAE. Через час или два производительность диска резко ухудшается, пока я не отбрасываю кеши, поэтому просто помещаю его в cron. Я не знаю, проблема ли это в ядре PAE или в том, что реализация кеша настолько медленная, если памяти достаточно.
Я видел, что кеши отбрасывания могут быть полезны при запуске группы виртуальных машин. Или что-нибудь еще, использующее большие страницы, например, некоторые серверы баз данных.
Большие страницы в Linux часто нуждаются в дефрагментации ОЗУ, чтобы найти 2 МБ непрерывной физической ОЗУ для размещения на странице. Освобождение всего файлового кеша делает этот процесс очень простым.
Но я согласен с большинством других ответов в том, что обычно нет веских причин сбрасывать файловый кеш каждую ночь.
Я могу придумать одну правдоподобную причину делать это в ночном задании cron.
В большой системе может быть полезно периодически отбрасывать кеши, чтобы можно было устранить фрагментацию памяти.
Прозрачная поддержка огромных страниц в ядре выполняет периодическую очистку памяти для объединения маленьких страниц в огромные страницы. В вырожденных условиях это может привести к паузам системы на минуту или две (мой опыт с этим был в RHEL6; надеюсь, он улучшился). Отбрасывание кешей может дать очистителю огромных страниц некоторое пространство для работы.
Вы можете возразить, что это хорошая причина для отключения прозрачных огромных страниц; OTOH вы можете полагать, что общее улучшение производительности от прозрачных огромных страниц стоит того, и стоит платить цену за потерю ваших кешей один раз в день.
Я придумал еще одну причину, по которой вы бы захотели это сделать, хотя и не в cron. Непосредственно перед тем, как система виртуализации перенесет виртуальную машину на новое оборудование, будет очень подходящим временем для этого. Меньше содержимого памяти для копирования на новый хост. В конечном итоге вам, конечно, придется читать из хранилища, но я, вероятно, пошел бы на этот компромисс.
Я не знаю, действительно ли это делает какое-либо программное обеспечение virt.
Вопрос с 2014 года, но, поскольку проблема существует и по сей день на некоторых скрытых серверных модулях centos 6.8, она может быть кому-то полезна.
https://github.com/zfsonlinux/zfs/issues/1548 описывает проблему с zfs. Там дисковое пространство не освобождается для удаленных файлов, потому что, если nfs используется поверх zfs, индексные дескрипторы файла не удаляются из кэша индексных дескрипторов ядра.
Цитата из цепочки сообщений об ошибках: behlendorf, 6 января 2015 г. писал:
Текущее предположение состоит в том, что по какой-то причине сервер NFS сохранение кэшированной версии дескриптора файла. Пока сервер NFS удаляет дескриптор файла. ZFS не может отсоединить этот файл. Некоторое легкое тестирование показал, что при удалении кешей на сервере эта ссылка быть отброшенным (как дескриптор файла NFS), в этот момент пространство правильно освободили. Недостаток памяти также может привести к его падению.
т.е. ночное эхо 3> / proc / sys / vm / drop_caches - самое простое исправление этой ошибки, если вы не хотите, чтобы у вас был простой для реструктуризации zfs.
Так что, возможно, не админка культа карго, но причина была в хорошей отладке.
Nke a nwere ike ịbụ ihe ezi uche dị na sistemụ NUMA (na-abụghị edo ebe nchekwa) usoro, ebe, Elezie, ọ bụla CPU (anya) nwere ike ịnweta niile na ebe nchekwa nghọta na ma ya na ebe nchekwa nwere ike enweta ngwa ngwa karịa ndị ọzọ anya si ebe nchekwa, na mmekorita ya na ngwa HPC ndị ọzọ.
Ọtụtụ ngwa yiri ngwa na-eme faịlụ I / O site na otu usoro,si otú ahapụ na ụzọ ọpụpụ a nnukwu nta nke ebe nchekwa na otu NUMA ọnụ ekenyela ka disk cache, mgbe na nke ọzọ NUMA ọnụ ebe nchekwa nwere ike ịbụ ọtụtụ n'efu. N'ọnọdụ ndị a, ebe usoro nchekwa dị na kernel Linux, dịka m maara, ka na-amabeghị NUMA, usoro ndị na-agba ọsọ na NUMA ọnụ nke nwere ebe nchekwa ekenyela ka nchekwa na-amanye igbunye ebe nchekwa na nọmba NUMA ọzọ, ọ bụrụhaala na enwere RAM n'efu na ọnụ nke ọzọ, si otú a na-egbu arụmọrụ ndị ahụ. 12145] Maka ngwa ndị na-abụghị otu nsogbu a agaghị enwe ike ibilite.
Когда кэш вашей страницы достаточно большой (намного больше, чем ваше текущее использование подкачки), и подкачка и выкачка происходят по очереди, это тот момент, когда вам нужно отбросить кэш. Я видел случаи, когда использование памяти увеличивалось на одном из моих серверов базы данных MariaDB под управлением Ubuntu 16.04LTS, и Linux просто решил увеличить использование подкачки вместо того, чтобы удалять неиспользуемые кэши страниц. Прозрачные hugepages уже отключены в моей системе, потому что TokuDB требовала его отключения. В любом случае, может быть, это и не ошибка, но Линукс, который все еще делает такое поведение, довольно озадачивает меня. Различные исходники утверждали, что Linux удалит кэш страниц, когда приложение запросит его :
Но реальность не так проста. Обходным решением является либо :
- Периодически
- Выполнять кэширование при необходимости (монитор, использующий vmstat 1 для подмены активности)
- Советовать 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
Это старо, и обратитесь к наиболее принятым ответам/ответам, почему бы не сделать это, но есть одно место, где я видел это как требование внутри гостя: хостинг-провайдер (название не упоминается), которое предоставляет очень дешевые виртуальные машины, но они, похоже, сильно превышают подписку и используют это, чтобы поддерживать свои системы «пригодными для использования», т.е. у вас нет очень быстрого ввода-вывода все время, и они очищают кеши, чтобы не делать такие вещи, как раздувание драйвера. Это говорит о том, что в основном люди не используют больше, чем часть выделенной ОЗУ, поэтому, очищая кеши (часто), они сохраняют фактическое использование ОЗУ в гостях и, следовательно, на хосте как можно ниже. т.е. больше виртуальных машин меньше физических, больше доход