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

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

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

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

80 голосов | спросил ivcode 20 Mayam14 2014, 07:12:02

12 ответов


84

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

ответил David Schwartz 20 Mayam14 2014, 08:59:44
62

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

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

ответил ananthan 20 Mayam14 2014, 10:26:34
34

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

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

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

  

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

     

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

ответил Joe 20 Maypm14 2014, 17:51:44
24

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

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

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

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

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

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

ответил PlasmaHH 20 Maypm14 2014, 23:46:50
16

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

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

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

ответил Zan Lynx 22 Mayam14 2014, 04:47:27
8

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

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

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

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

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

Нижняя линия

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

ответил David Wilkins 20 Maypm14 2014, 19:16:41
4

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

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

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

ответил mirabilos 21 Maypm14 2014, 12:03:11
3

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

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

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

ответил Guntram Blohm 21 Mayam14 2014, 10:20:56
3

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

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

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

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


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

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

ответил Dan Pritts 14 Jpm1000000pmWed, 14 Jan 2015 18:43:21 +030015 2015, 18:43:21
2

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

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

ответил aularon 26 Maypm14 2014, 15:04:49
1

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

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

Чтобы процитировать сообщение об ошибке, behlendorf, 6 января 2015 г. писал (а):

  

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

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

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

ответил Iridos 27 +03002017-10-27T15:25:26+03:00312017bEurope/MoscowFri, 27 Oct 2017 15:25:26 +0300 2017, 15:25:26
-5

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

ответил kyku 23 Maypm14 2014, 12:32:33

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132