Я могу настроить свою систему Linux для более агрессивного кэширования файловой системы?

Во-первых, я НЕ рекомендую продолжить использовать NTFS, поскольку ntfs implemention в Linux была бы производительность и проблема безопасности в любое время.

Существует несколько вещей, которые можно сделать:

• используйте некоторую более новую фс такой как ext4 или btrfs
• попытайтесь изменить свой io планировщик, например bfq
• выключите подкачку
• используйте некоторый автоматический предварительный загрузчик как preload
• используйте что-то как systemd предварительно загружать при начальной загрузке
• ... и что-то больше

Возможно, Вы хотите дать ему попытку :-)

Можно установить считанный вперед размер с blockdev --setra sectors /dev/sda1, где секторы являются размером, Вы хотите в 512-байтовых секторах.

Чтение вперед:

В системах на 32 бита:

blockdev --setra 8388607 /dev/sda

В системах на 64 бита:

blockdev --setra 4294967295 /dev/sda

Запись позади кэша:

echo 100 > /proc/sys/vm/dirty_ratio

Это будет использовать до 100% Вашей свободной памяти как кэш записи.

Или можно полностью выложиться и использовать tmpfs. Это только релевантно, если у Вас есть RAM достаточно. Вставьте это /etc/fstab. Замена 100G с суммой физической RAM.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

Затем:

mkdir /mnt/tmpfs; mount -a

Затем используйте/mnt/tmpfs.

Улучшение производительности дискового кэша в целом больше, чем просто увеличивает размер кэша файловой системы, если Ваша целая система не помещается в RAM, в этом случае, необходимо использовать Электронный диск (tmpfs хорошо, потому что это позволяет отступать к диску при необходимости в RAM в некотором случае) для устройства хранения данных во время выполнения (и возможно initrd сценарий для копирования системы с устройства хранения данных на Электронный диск при запуске).

Вы не сказали, является ли Вашим устройством хранения SSD или жесткий диск. Вот то, что я нашел для работы на меня (в моем случае sda жесткий диск, смонтированный в /home и sdb SSD, смонтированный в /).

Сначала оптимизируйте load-stuff-from-storage-to-cache часть:

Вот моя установка для жесткого диска (удостоверьтесь, что AHCI+NCQ включен в BIOS, если у Вас есть переключатели):

echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda

Стоящий замечания случаем жесткого диска высоко fifo_expire_async (обычно пишите), и долго slice_sync позволить единственному процессу получать высокую пропускную способность (набор slice_sync понизить число, если Вы поражаете ситуации, где несколько процессов ожидают некоторых данных из диска параллельно). slice_idle всегда компромисс для жестких дисков, но установка его где-нибудь в диапазоне 3-20 должна быть хорошо в зависимости от использования диска и микропрограммы диска. Я предпочитаю быть нацеленным для низких значений, но установка его слишком низко уничтожит Вашу пропускную способность. quantum установка, кажется, влияет на пропускную способность много, но пытается сохранить это максимально низко для хранения задержки на разумном уровне. Установка quantum слишком низко уничтожит пропускную способность. Значения в диапазоне 3-8, кажется, работают хорошо с жесткими дисками. Худшая задержка случая для чтения (quantum * slice_sync) + (slice_async_rq * slice_async) мс, если я понял поведение ядра правильно. Асинхронное главным образом используется записями и так как Вы готовы задержать запись в диск, установить обоих slice_async_rq и slice_async к очень небольшим числам. Однако установка slice_async_rq слишком низкая стоимость может остановить чтения, потому что записи не могут откладываться после чтений больше. Моя конфигурация попытается записать данные в диск самое большее после спустя 10 секунд после того, как данные были переданы ядру, но так как можно терпеть потерю данных по потерям мощности также набор fifo_expire_async кому: 3600000 сказать, что 1 час хорошо для задержки с диском. Просто сохраните slice_async низко, тем не менее, потому что иначе можно получить высокую задержку чтения.

hdparm команда требуется, чтобы препятствовать тому, чтобы AAM уничтожил большую часть производительности, которую позволяет AHCI+NCQ. Если Ваш диск делает слишком много шума, то пропустите это.

Вот моя установка для SSD (ряд Intel 320):

echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync

Здесь стоит отметить низкие значения различными настройками части. Самая важная установка для SSD slice_idle который должен быть установлен на 0-1. Установка его для обнуления перемещает все решения упорядочивания в собственный NCQ, в то время как установка его к 1 позволяет ядру заказывать запросы (но если NCQ активен, аппаратные средства могут переопределить ядро, заказывающее частично). Протестируйте оба значения, чтобы видеть, видите ли Вы различие. Для ряда Intel 320 это кажется той установкой slide_idle кому: 0 дает лучшую пропускную способность, но установку его к 1 дает лучше всего (самую низкую) полную задержку.

Для получения дополнительной информации об этих tunables, см. https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt.

Теперь, когда мы настроили ядро для загрузки материала от диска до кэша с разумной производительностью, пора скорректировать поведение кэша:

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

Система набора, чтобы предпочесть подкачивать данные файла по коду приложения (это не имеет значения, есть ли у Вас достаточно RAM для хранения целой файловой системы и всего кода приложения и всей виртуальной памяти выделенными приложениями в RAM). Это уменьшает задержку для свопинга между различными приложениями по задержке для доступа к большим файлам из отдельного приложения:

echo 15 > /proc/sys/vm/swappiness

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

Я в наше время (2017) предпочитаю не иметь никакой подкачки вообще, если у Вас есть достаточно RAM. Наличие никакой подкачки будет обычно терять 200-1000 МБ RAM на длительной настольной машине. Я готов пожертвовать так многим для предотвращения худшей задержки варианта развития событий (загружающий код приложения, когда RAM полна). На практике это означает, что я предпочитаю Уничтожителя OOM свопингу. Если Вы позволяете/нуждаетесь подкачивать, Вы могли бы хотеть увеличиться /proc/sys/vm/watermark_scale_factorТакже избегать некоторой задержки. Я предложил бы значения между 100 и 500. Можно рассмотреть эту установку как торговое использование ЦП для более низкой задержки подкачки. Значение по умолчанию равняется 10, и возможный максимум 1000. Более высокое значение должно (согласно документации ядра) результат в более высоком использовании ЦП для kswapd процессы и более низкая полная задержка свопинга.

Затем, скажите ядру предпочитать сохранять иерархию каталогов в памяти по содержанию файла в случае, если некоторая RAM должна быть освобождена (снова, если все помещается в RAM, эта установка ничего не делает):

echo 10 > /proc/sys/vm/vfs_cache_pressure

Установка vfs_cache_pressure к низкой стоимости имеет смысл, потому что в большинстве случаев, ядро должно знать структуру каталогов, прежде чем это сможет использовать содержание файла от кэша, и сбрасывание кэша каталога слишком скоро сделает кэш файла рядом с бесполезным. Рассмотрите движение полностью вниз к 1 с этой установкой, если у Вас есть много маленьких файлов (моя система имеет вокруг 150K фотографий на 10 мегапикселей и количеств как "много маленьких файлов" система). Никогда не обнуляйте его, или структура каталогов всегда сохраняется в памяти, даже если система исчерпывает память. Установка этого к большому значению разумна, только если у Вас есть только несколько больших файлов, которые постоянно перечитываются (снова, редактирование HD-видео без достаточного количества RAM было бы случаем в качестве примера). В официальной документации ядра говорится, что "увеличение vfs_cache_pressure значительно вне 100 может оказать отрицательное влияние производительности".

Исключение: если у Вас есть действительно значительная сумма файлов и каталогов, и Вы редко касаетесь/читаете/перечисляете всей установки файлов vfs_cache_pressure выше, чем 100 может быть мудрым. Это только применяется, если Вы не имеете достаточного количества RAM и не можете сохранить целую структуру каталогов в RAM и все еще имеющий достаточно RAM для нормального кэша файла и процессов (например, общекорпоративный файловый сервер с большим количеством архивного содержания). Если Вы чувствуете, что необходимо увеличиться vfs_cache_pressure выше 100 Вы работаете без достаточного количества RAM. Увеличение vfs_cache_pressure может помочь, но единственная реальная фиксация должна получить больше RAM. Наличие vfs_cache_pressure набор к высокому количеству жертвует средней производительностью за то, что она имела более стабильную работу в целом (то есть, можно избежать действительно плохого худшего поведения случая, но иметь для контакта с худшей общей производительностью).

Наконец скажите ядру использовать до 99% RAM как кэш для записей и давать ядру команду использовать до 50% RAM перед замедлением процесса, который это пишет (значение по умолчанию для dirty_background_ratio 10). Предупреждение: Я лично не сделал бы этого, но Вы утверждали, что имели достаточно RAM и готовы потерять данные.

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

И скажите, что задержка записи 1 ч в порядке, чтобы даже начать писать материал на диске (снова, я не сделал бы этого):

echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs

Для получения дополнительной информации об этих tunables, см. https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Если Вы помещаете всех тех, которые к /etc/rc.local и включайте следующее в конец, все будет в кэше как можно скорее после начальной загрузки (только делают это, если Ваша файловая система действительно помещается в RAM):

(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

Или немного более простая альтернатива, которая могла бы работать лучше (кэш только /home и /usr, только сделайте это если Ваш /home и /usr действительно поместитесь в RAM):

(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

Моя уничтожающая установка является очень простой и очень эффективной:

echo "2000" > /proc/sys/vm/vfs_cache_pressure

Объяснение из документации ядра:

vfs_cache_pressure

Управляет тенденцией ядра исправить память, которая используется для кэширования объектов inode и каталога.

В значении по умолчанию vfs_cache_pressure=100 ядро попытается исправить dentries и inodes на "справедливом" уровне относительно pagecache, и swapcache исправляют. Уменьшение vfs_cache_pressure заставляет ядро предпочитать сохранять dentry и inode кэши. Когда vfs_cache_pressure=0, ядро никогда не будет исправлять dentries и inodes из-за давления памяти, и это может легко привести к условиям из памяти. Увеличение vfs_cache_pressure вне 100 причин ядро, чтобы предпочесть исправлять dentries и inodes.

vfs_cache_pressure в 2 000 причин, что большинство вычислений происходит в RAM и очень последних записях на диск.

Не относится к кэшированию записи, но относится к записи:

• Для системы ext4 вы можете полностью отключить ведение журнала

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

Чтобы чтение с диска не запускало запись на диск:

• Крепление с опцией relatime или noatime

  Когда вы читаете файл, метаданные «время последнего доступа» для этого файла обычно обновляются. Опция noatimeотключит это поведение. Это уменьшит количество ненужных операций записи на диск, но у вас больше не будет этих метаданных. Некоторые дистрибутивы (, например. Manjaro )принял это по умолчанию для всех разделов (, вероятно, чтобы увеличить срок службы более ранних моделей SSD ).

  relatimeобновляет время доступа реже, в соответствии с эвристикой, которая помогает поддерживать приложения, использующие atime. Это значение по умолчанию в Red Hat Enterprise Linux.

Другие опции:

• В комментариях выше Микко поделился возможностью монтажа с опцией без барьера . Но Ivailo цитирует RedHat , который предостерегает от этого. Насколько сильно вы хотите эти дополнительные 3%?