Каталог силы, чтобы всегда быть в кэше

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

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

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

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

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

Точка должна измениться swappiness. Давайте рассмотрим три основных типа использования памяти: активные программы, неактивные программы и дисковый кэш. Очевидно, память, используемая активными программами, не должна быть выгружена, и выбор между двум другим довольно произволен. Хотели бы Вы быстрое переключение программы или быстрый доступ к файлу? Низкий 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/.

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

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

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

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

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

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

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

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

Это не может быть самым лучшим решением, но оно хорошо подошло мне.

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

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

vmtouch -dl /whatever/directory/

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

Этот скрипт будет хранить каталоги в кэше.

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

echo $smallnumber > /proc/sys/vm/vfs_cache_pressure— это то, как Linux автоматически настраивает кэш каталогов. Он работает с этим сценарием, чтобы сообщить Linux, какие каталоги недавно использовались.