Вопрос: Зачем бросать кеши в Linux?


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

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

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


80
2018-05-20 03:12


Источник


Найдите человека, который положил это, и спросите его, почему он это сделал. Как вы правильно догадались, для этого нет очевидной веской причины. - Michael Hampton♦
Отладка ядра. Вот и все. Это фактически не освобождает RAM; он бросает кеши, как следует из названия, и, следовательно, снижает производительность. - Michael Hampton♦
@ivcode Затем вы должны найти и исправить проблему с этим сервером, а не пытаться избежать условий, вызывающих это. Если мой автомобиль застопорился каждый раз, когда я делал резкий поворот вправо, избегая острых поворотов вправо, это отвратительное исправление. - David Schwartz
Связанный thedailywtf.com/Articles/Modern-Memory-Management.aspx Строго утверждая, что это плохая идея. - Drunix
Связанное и полезное описание «проблемы»: linuxatemyram.com - Bill Weiss


Ответы:


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


84
2018-05-20 04:59



+1 для упоминания Администрации системы кустарного грунта. Любой системный администратор, который не знает этого термина и что он означает, должен быть уволен. - Tonny
@Tonny: Мы остались бы без sysadmin отдела тогда :( - PlasmaHH
Как и большинство людей, я обожаю красноречивые утверждения с большим одобрением, но цитата или рассуждение заработают мой суперэго +1. - Aaron Hall
Объясните администрацию груза и культа, а также вышесказанное, если вы не возражаете. Может быть, в последующем редактировании? Я все еще отказываюсь от своего +1 ...: P - Aaron Hall
«возможно, что, хотя ваше приложение не может использовать эту оперативную память, но Linux агрессивно кэширует свою память, и хотя приложение нуждается в памяти, оно не освободит некоторые из этих кешей, но скорее начнет замену». Не очень конкретный. На практике управление памятью не является совершенным и имеет ручку, чтобы поворачиваться, когда появляется это несовершенство. - Dan Pritts


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

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


62
2018-05-20 06:26



+1 для объяснения Зачем это плохая идея. - Ogre Psalm33


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

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

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

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

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


34
2018-05-20 13:51



Конечно, в зависимости от того, что вы пытаетесь сделать, даже полная перезагрузка может недостаточно очистить кэш диска. - Michael Kjörling
«эти объекты автоматически восстанавливаются ядром, когда требуется память» - это цель дизайна, но это может быть не всегда фактическое поведение. - Dan Pritts
@DanPritts Что именно заставляет вас думать, что это не так? - Joe
Очевидным случаем является то, что вы хотите очистить ОЗУ, чтобы позволить выделять больше (не-trnsparent) огромных страниц; другим случаем является прозрачная огромная сборка мусора для сбора мусора (см. мой ответ / комментарии в другом месте по этому вопросу). Но мой комментарий был предназначен для общего дела. Иногда люди, которые работают в системе, знают лучше, чем люди, которые его разработали / внедрили. Часто это не так - это то, что их комментарий пытается защитить. Я просто рад, что - Dan Pritts


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

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

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

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

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

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


24
2018-05-20 19:46



Все приложения на моем сервере работают на nohup. Может быть, nohup.out кэшируется и ел память? - ivcode
@ivcode: Это может быть причиной, проверьте, насколько велика nohup.out. Возможно, используйте vmtouch, чтобы выяснить, сколько из них кэшировано. - PlasmaHH
У меня есть работа cron cat /dev/null > path/nohup.out каждые 15 минут, поскольку nohup.out быстро растет. Возможно, linux кэширует nohup.out, даже если я его очищаю - ivcode
@ivcode Если вам не нужен вывод из nohup вы должны перенаправить его на /dev/null, Похоже, в какой-то момент у вас были очень неопытные системные администраторы, работающие над вашими системами. Видеть stackoverflow.com/questions/10408816/... о том, как направить nohupвыход на /dev/null - David Wilkins
хотя nohup.out очищается с интервалом в 15 минут, если по какой-либо причине процесс приложения был убит, nohup.out будет автоматически выполняться с другого сценария. Я попробовал vmtouch. это очень хороший инструмент - ivcode


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

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

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


16
2018-05-22 00:47



Я поддержал, указав, что предубеждение второго порядка - это ответы на патчи. - Noah Spurrier
Кроме того, в приложениях HPC на узлах с высокой памятью (1Tb) чтение в нескольких больших файлах приводит к большому объему кэширования памяти. Поскольку многие приложения HPC выполняют функции malloc сотен ГБ, система может работать в течение нескольких часов, так как процессы миграции перемещают крошечные фрагменты фрагментированной памяти бесцельно через узлы NUMA, когда система достигает границы «кэшированной» памяти. Хуже того, вы ничего не можете сделать в userland, чтобы освободить кеши, за исключением того, что система выделяет все крошечные блоки размером 2 Мбайт, которые она может сразу же освобождать, позволяя огромной дефрагментации и приложения запускаться нормально. - user1649948
+1 Команда создания больших страниц (sysctl -w vm.nr_hugepages=...) отказывается даже работать, если я сначала не удаляю кеши (Arch linux). - Aleksandr Dubinsky


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

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

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

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

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

Нижняя линия

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


8
2018-05-20 15:16





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

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

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


4
2018-05-21 08:03



«ошибка ядра, из-за которой kswapd сходит с ума». Какая ошибка? - Ben
@Ben видеть эта тема (это сообщение и пара последующих действий, одна из которых включает в себя догадки, откуда это может произойти) - mirabilos
Я испытываю подобную проблему (хотя это x86_64), и единственным решением на данный момент является падение кэшей serverfault.com/questions/740790/... - Fernando
@Fernando У меня есть «кэширование кэшей» в поле m68k - mirabilos


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

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

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


3
2018-05-21 06:20





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

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

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

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


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

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


3
2018-01-14 15:43



У вас есть источник для этого? Это похоже на то, что должно быть исправлено в ядре, если это такая проблема. - gparent
У меня есть личный опыт с паузами с прозрачными огромными страницами. RHEL6, Dell R810, 4CPU, 64 ГБ оперативной памяти. Отключение прозрачных огромных страниц (есть файл / proc для этого) немедленно устраняет паузы. В то время я не пробовал технику кэширования; вместо этого я переконфигурировал наши приложения Java для использования непрозрачных огромных страниц и оставил прозрачные огромные страницы отключенными. IIRC, мы рассмотрели ситуацию достаточно, чтобы понять, что мы не единственные пострадавшие люди, и что Red Hat знает об этой проблеме. - Dan Pritts
Привет, Dan, я поддерживаю такое же поведение на своем сервере. Я работаю с огромным объемом данных, и после 10 + вычислений одной и той же программы python наблюдается резкое падение производительности (x2-3 первого времени вычисления). Если взглянуть, размер кеша памяти огромен, 100 + ГБ. И если я сброшу этот кэш памяти и заново запустил свою программу, я верну свое начальное время вычисления. У вас есть какой-либо документ или информация, чтобы поделиться этим явлением? Спасибо. - Axel Borja
access.redhat.com/solutions/46111 описывает это. Вы можете отключить прозрачные огромные страницы, чтобы убедиться, что это проблема в вашем случае. - Dan Pritts