Принудительно, чтобы каталог всегда был в кеше

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

Очевидно, что работа с RAM-диска не практична. Итак, кто-нибудь знает, как я могу заставить ОС всегда сохранять определенный каталог в кэше ? Я все еще хочу, чтобы каталог синхронизировался обратно на диск, как обычно, но я всегда хочу и копию данных в памяти. Это возможно?

РЕДАКТИРОВАТЬ: Как возможное решение, мы только что подумали о запуске демона, который запускается rsyncкаждые 10 секунд или около того, чтобы синхронизировать диск с RAM-диском. Затем мы запускаем компиляцию с RAM-диска. Это rsyncбыстро, но будет ли это работать? Конечно, ОС может работать лучше ....

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

Попробуйте наблюдать за тем, что делает IO в каждом случае. Основным инструментом для этого является iotop. Другие инструменты могут быть полезны; увидеть распределение нагрузки ввода-вывода диска Linux по пути к файловой системе и / или процессу? , Что программы в Linux можно измерить I / O в течение долгого времени? и другие темы при сбое сервера.

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

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

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

Дело в том, чтобы изменить swappiness. Рассмотрим три основных типа использования памяти: активные программы, неактивные программы и дисковый кеш. Очевидно, что память, используемая активными программами, не должна быть выгружена, и выбор между двумя другими совершенно произвольный. Хотите быстрое переключение программ или быстрый доступ к файлам? Низкий swappiness предпочитает держать в памяти программ (даже если он не используется в течение длительного времени) и высокой swappiness предпочитает держать больше дискового кэша (путем замены неиспользуемых программ). (шкала перестановки от 0 до 100 и значение по умолчанию 60)

Мое решение вашей проблемы состоит в том, чтобы изменить swappiness на очень высокий (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 и других используемых программ.

Форсирование кеша не является правильным способом сделать это. Лучше хранить исходники на жестком диске и компилировать их в tmpfs. Многие системы сборки, такие как qmake и CMake, поддерживают сборки вне исходного кода.

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

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

vmtouch, кажется, делает именно это. Пример 5 там может быть то, что вам нужно.

vmtouch -dl /whatever/directory/

Мне нужно было запустить его как root с sudo

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

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

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

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

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

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

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

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

Возможно, это не самое лучшее решение, но оно мне подходит.