Примушуйте каталог завжди бути в кеші


35

Я випробовував різні методи, щоб поліпшити час, необхідний для складання всього мого проекту c ++. В даний час це займає ~ 5 хвилин. Я експериментував з distcc, ccache та іншими. Нещодавно я виявив, що якщо я копіюю весь свій проект на RAM-диск, а потім компілюю звідти, він скорочує час компіляції до 30% від його початкового - всього 1,5 хвилини.

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

EDIT: Як можливе рішення, ми просто задумали запустити демон, який працює rsyncкожні 10 секунд або близько того, щоб синхронізувати дисковий диск з накопичувачем RAM. Потім ми запускаємо компіляцію з накопичувача оперативної пам'яті. Це rsyncшвидко палає, але чи справді це би спрацювало? Звичайно, ОС могла б зробити краще ...


Кеш - не єдина різниця між tmpfs та ext3 / 4; Наприклад, у них є журнал, який буде написаний незалежно від кешування.
Андре Парамеш

1
Чи можете timeви скласти свою збірку та поділитися результатом з нами? Це розвіяло б певні суперечки. make clean && /usr/bin/time -v make(не використовуйте вбудовану timeкоманду bash )
shellholic

1
@she Чому б не вбудована команда bash?
thepang

3
@Thepang timeвбудований в bash ( help time) має набагато менше деталей (без багатослівного вибору), ніж час GNU ( man time) щодо вводу-виводу, контекстних комутаторів, ...
shellholic

Відповіді:


18

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

Спробуйте спостерігати за тим, що робить IO у кожному конкретному випадку. Основним інструментом для цього є iotop. Інші інструменти можуть бути корисні; див. розбивка завантаження IO диска Linux за маршрутом файлової системи та / або процесом? , Яка програма в Linux може вимірювати введення-виведення з часом? та інші потоки в серверній помилці.

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

  • Якщо у вас увімкнено час доступу до файлів , ОС може витратити зовсім небагато часу на написання цих часів доступу. Часи доступу для дерева компіляції марні, тому переконайтеся, що вони вимкнено за допомогою noatimeпараметра монтажу. Ваше рішення tmpfs + rsync ніколи не зчитується з жорсткого диска, тому ніколи не потрібно витрачати зайвий час на написання атмерів.
  • Якщо записи синхронізуються , або тому, що компілятор викликає, sync()або через те, що ядро ​​часто промиває свої вихідні буфери, записи триватимуть довше на жорсткий диск, ніж до tmpfs.

У мене теж є таке відчуття. Компіляція інтенсивніше процесора, а не IO.
phunehehe

Гммм, я хотів би побачити тут коментар від @JaredC, який підтверджує або заперечує гіпотезу Гілла. 1,5 проти 5 мінусів - це досить велика різниця ...
Даніель Альдер

8

Linux за замовчуванням використовує оперативну пам’ять як кеш диска. Як демонстрація, спробуйте запустити time find /some/dir/containing/a/lot/of/files > /dev/nullдва рази, другий раз набагато швидше, оскільки всі дискові вставки кешуються. Суть у тому, як скористатися цією функцією ядра та зупинити вашу спробу заміни.

Сенс у тому, щоб змінити swappiness. Розглянемо три основні типи використання пам'яті: активні програми, неактивні програми та кеш диска. Очевидно, що пам'ять, яку використовують активні програми, не слід замінювати, а вибір між двома іншими є досить довільним. Ви хочете швидкої комутації програми або швидкого доступу до файлів? Низький swappiness воліє тримати в пам'яті програм (навіть якщо він не використовується в протягом тривалого часу) і високою swappiness воліє тримати більше дискового кешу (шляхом заміни невикористовуваних програм). (шкала заміщення - від 0 до 100, а значення за замовчуванням - 60)

Моє рішення вашої проблеми - змінити свопість на дуже високу (90-95 не сказати 100) і завантажити кеш:

echo 95 | sudo tee /proc/sys/vm/swappiness > /dev/null # once after reboot
find /your/source/directory -type f -exec cat {} \; > /dev/null

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


Це взагалі корисно, але те, що я дійсно хочу, - це те, щоб у моєму вихідному коді була низька простота, а все інше - мати нормальну заміщення. По суті, у мене багато чого відбувається у фоновому режимі, але я хочу обмежити їх на 6 з 8 ГБ, при цьому завжди зберігаючи інші 2 ГБ для вихідного коду. Я не хочу ризикувати, що він поміняється ... ніколи ... бо це дратує.
JaredC

Замінність є системою. Насправді, якщо ви робите щось інше, і ваші файли вивантажуються з пам'яті, вам просто доведеться перезавантажити його другим рядком. Якщо пам'ять потрібно звільнити заради чогось іншого, ви насправді не «бажаєте ризикнути», щоб це було зроблено за допомогою swap. До речі, tmpfsу тому ж випадку також буде замінено.
панцирік

2
Особисто я впав, на робочих робочих місцях велика примхливість або дуже жахлива. Хоча деякі функції можуть бути прискорені за рахунок більшого кешу (тобто більше кешованих файлів), це коштує: ви платите за це з точки зору чуйності при переключенні між програмами, що саме користувачі спочатку помічають під час роботи в системі. При переході з браузера в офіс на інший браузер на електронну пошту я просто не можу дотримуватися часу, коли потрібно чекати 1-2 секунди, щоб кожна програма знову змінилася. На всіх моїх машинах Linux я зазвичай встановлюю простоту на низьке значення 10.
fgysin відновила Моніку

6

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


6

Ці inosyncзвуки демона , як це робить саме те , що ви хочете , якщо ви збираєтеся Rsync до псевдодіску. Замість того, щоб rsyncing кожні 10 секунд або близько того, він використовує інструмент інотифікації Linux для rsync, коли файл змінюється. Я знайшов його в сховищі Debian як inosyncпакет, або його джерело доступне за посиланням http://bb.xnull.de/projects/inosync/ .


Це звучить досить корисно. Я перегляну його і звіту. Спасибі!
JaredC

5

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

vmtouch, здається, робить саме цю справу. Приклад 5 може бути те, що вам потрібно.

vmtouch -dl /whatever/directory/

Мені потрібно було запустити його як root sudo


1
Він не бачить нових / видалених файлів.
Ві.

3

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

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

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

Ви можете отримати деяку продуктивність, використовуючи розділ ext2 з вимкненим atime. Ваш джерело повинен знаходитись у контролі версій у файловій системі, що використовується в журналі, наприклад ext3 / 4.


2

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

Ви можете автоматизувати це, написавши скрипт для моніторингу результатів vmstat 1(використовуйте будь-який еквівалентний інструмент для вашої ОС) та зберігайте суму кількості написаних та прочитаних блоків. Як тільки сума перейде поріг, який ви обрали, прочитайте всі файли, які ви хочете кешувати, скиньте суму, а потім продовжуйте моніторинг виводу vmstat. Швидке читання файлів: якщо ваше дерево містить багато файлів, уникайте find ... -exec cat, замість цього спробуйте find ... -print0 | xargs -0 catабо користувальницьку програму, яка не виконує кот для кожного файлу.

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

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

Це може бути не найкращим можливим рішенням, але воно мені добре підходило.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.