Навіщо скидати кеші в Linux?

На наших серверах у нас є звичка скидати кеші опівночі.

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

Коли я запускаю код, то, здається, звільняється багато оперативної пам’яті, але чи дійсно мені це потрібно зробити. Хіба безкоштовна оперативна пам’ять не є відходом?

Ви на 100% правильні. Це НЕ хороша практика , щоб звільнити пам'ять. Це, мабуть, приклад управління системою культового культу.

Так, очищення кешу звільнить оперативну пам’ять, але це змушує ядро ​​шукати файли на диску, а не в кеші, що може спричинити проблеми з продуктивністю.

Зазвичай ядро ​​очистить кеш-пам'ять, коли наявна ОЗУ буде вичерпана. Він часто записує забруднений вміст на диск, використовуючи pdflush.

Причина скидати кеші на кшталт цього полягає в тестуванні продуктивності диска, і є єдиною причиною його існування.

Під час роботи інтензивного введення / виводу, ви хочете бути впевнені, що різні налаштування, які ви намагаєтеся, насправді роблять дискові введення / виведення, тому Linux дозволяє вам скидати кеші, а не робити повну перезавантаження.

Цитувати з документації :

Цей файл не є засобом контролю за ростом різних кешів ядра (inode, dentries, pagecache тощо). Ці об'єкти ядра автоматично відновлюються, коли пам'ять потрібна в іншому місці системи.

Використання цього файлу може спричинити проблеми з продуктивністю. Оскільки він відкидає кешовані об'єкти, це може коштувати значної кількості вводу-виводу та процесора для відтворення викинутих об'єктів, особливо якщо вони були під значним використанням. Через це використання в середовищі тестування або налагодження не рекомендується.

Основна ідея тут, мабуть, не така вже й погана (просто дуже наївна і вводить в оману): Можуть бути кешовані файли, до яких навряд чи можна отримати доступ найближчим часом, наприклад, реєстраційні файли. Ці барани "з'їдають", які пізніше доведеться звільняти при необхідності ОС тим чи іншим чином.

Залежно від ваших налаштувань простоти, схеми доступу до файлів, схеми розподілу пам’яті та багатьох інших непередбачуваних речей, може статися, що коли ви не будете звільняти ці кеші, вони згодом будуть змушені повторно використовуватися, що займе трохи більше часу, ніж виділення пам'яті з пула невикористаної пам'яті. У гіршому випадку налаштування простоти в Linux спричинить заміну пам'яті програми, оскільки Linux вважає, що ці файли можуть бути скоріше використані найближчим часом, ніж пам'ять програми.

У моєму середовищі Linux часто здогадується неправильно, і на початку більшості європейських фондових бірж (близько 09:00 за місцевим часом) сервери почнуть робити те, що вони роблять лише один раз на день, потребуючи обміну пам’яттю, яка раніше була замінена через те, що пишуть журнали, стискаючи їх, копіюючи їх тощо, заповнювали кеш до того моменту, коли речі потрібно було замінити.

Але чи відмова кешів вирішує цю проблему? однозначно ні. Що б тут було рішення - сказати Linux, що він не знає: ці файли, ймовірно, більше не будуть використовуватися. Це можна зробити за допомогою програми для написання, використовуючи такі речі, як posix_fadvise()інструмент cmd line vmtouch(наприклад, який також можна використовувати для перегляду речей, а також файлів кешу).

Таким чином ви можете видалити дані, які більше не потрібні з кеш-пам'яті, і зберегти ті матеріали, які слід кешувати, тому що, коли ви скидаєте всі кеші, багато чого потрібно перечитати з диска. І це в найгірший можливий момент: коли це потрібно; спричиняючи затримки у вашій програмі, помітні і часто неприйнятні.

Що вам слід створити - це система, яка моніторить ваші шаблони використання пам'яті (наприклад, якщо щось змінюється), а потім аналізує їх відповідно і діє відповідно. Рішенням може бути виселення великих файлів наприкінці дня за допомогою vtouch; можливо також додати більше оперативної пам’яті, оскільки щоденне пікове використання сервера - це саме те.

Я бачив, що кеші крапель є корисними при запуску ряду віртуальних машин. Або що-небудь інше, що використовує великі сторінки, такі як деякі сервери баз даних.

Великі сторінки в Linux часто потребують дефрагментації оперативної пам’яті, щоб знайти 2 Мб суміжної фізичної оперативної пам’яті для розміщення на сторінці. Звільнення всього кеш-файлів робить цей процес дуже простим.

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

Цілком можливо, що це було встановлено як спосіб стабілізації системи, коли не було нікого з навичками чи досвідом, щоб реально знайти проблему.

Звільнення ресурсів

Видалення кеш-файлів фактично звільнить деякі ресурси, але це побічно впливає на те, що система насправді працюватиме важче, щоб зробити те, що намагається зробити. Якщо система проводить обмін (намагається читати та записувати з розділу диска своп швидше, ніж це насправді можливо), то періодичне видалення кешів може полегшити симптом , але нічого не робить для усунення причини .

Що їсть пам’ять?

Ви повинні визначити, що спричиняє велику витрату пам’яті, а це здається, що спрацьовування кешів працює. Це може бути викликано будь-якою кількістю погано налаштованих або просто неправильно використаних серверних процесів. Наприклад, на одному сервері я спостерігав максимум використання пам’яті, коли веб-сайт Magento протягом 15 хвилин пройшов певну кількість відвідувачів. Це призвело до того, що Apache був налаштований так, щоб дозволити одночасно запускати занадто багато процесів. Занадто багато процесів, використовуючи багато пам’яті (Магенто іноді є звіром) = міняти місцями.

Нижня лінія

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

У Linux / m68k насправді є помилка в ядрі, яка змушує kswapd зійти з розуму і з'їсти 100% процесора (50%, якщо є якесь інше завдання, пов'язане з процесором, як, наприклад, автобілдер двобічного пакету Debian - vulgo buildd - вже працює), який може (більшість часу; не завжди) пом'якшуйте, виконуючи цю конкретну команду кожні кілька годин.

Але це означає, що ваш сервер, швидше за все, не система m68k (Atari, Amiga, Classic Macintosh, VME, Q40 / Q60, Sun3) ;-)

У цьому випадку людина, яка поставила рядки, або дотримувалася певних сумнівних, або, у кращому випадку, застарілих порад, або отримала уявлення про те, як слід використовувати оперативну пам’ять неправильно (сучасне мислення справді говорить, що «вільна оперативна пам’ять втрачається оперативної пам’яті» та пропонує кешування) або "виявив", що це "виправляє" [sic!] іншу проблему в іншому місці (і було занадто ліниво шукати належне виправлення).

Однією з причин може бути те, що на сайті працює якийсь моніторинг, який перевіряє кількість безкоштовного тарана і надсилає попередження адміністраторам, коли безкоштовний операційний бал падає нижче певного відсотка. Якщо цей інструмент моніторингу досить тупий, щоб не включати кеш у вільний розрахунок оперативної пам'яті, він може надсилати помилкові попередження; регулярне спорожнення кешу може придушити ці попередження, при цьому все ж дозволяючи інструменту помітити, коли "справжній" баран стає низьким.

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

Тож навіть якщо моє припущення вірно, очищення кешу - це не те, що має сенс, це скоріше врегулювання того, хто недостатньо компетентний, щоб виправити основну проблему.

Я можу придумати одну правдоподібну причину робити це в нічній роботі з крон.

У великій системі може бути корисно періодично скидати кеші, щоб ви могли видалити фрагментацію пам'яті.

Підтримка прозорої величезної сторінки ядра робить періодичну розгортання пам'яті, щоб об'єднати невеликі сторінки у величезні сторінки. У вироджених умовах це може призвести до системних пауз на хвилину-дві (мій досвід з цим був у RHEL6; сподіваюся, він покращився). Випадання кеш-пам’яток може дати можливість розметувачам величезних сторінок мати місце для роботи.

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

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

Я не знаю, чи справді це робить програмне забезпечення Virt.

Тільки, щоб додати два мої центи: Система дуже добре знає, що ці сторінки пам'яті є кешами, і випаде стільки, скільки потрібно, коли програма запитує про пам'ять.

Відповідне налаштування - /proc/sys/vm/swappinessце вказує ядру під час нових розподілів пам’яті віддавати перевагу скиданням кеш-пам’яті або підміняти «непрацюючі» виділені сторінки пам'яті.

Питання йдеться про 2014 рік, але оскільки проблема існує і донині на деяких прихованих центрових 6.8 міграціях, вона все ще може бути корисною для когось.

https://github.com/zfsonlinux/zfs/isissue/1548 описує проблему з zfs. Там дисковий простір не видаляється для видалених файлів, оскільки якщо nfs використовується поверх zfs, то вставки файлу не випадають з кеш-пам'яти ядра.

Для цитування з теми помилок, behlendorf, 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 run:

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 або з тим, що реалізація кешу настільки повільна, якщо є багато пам'яті.