Улучшение производительности дискового кеша в целом - это больше, чем просто увеличение размера кеша файловой системы, если только вся ваша система не помещается в ОЗУ, в этом случае вам следует использовать ОЗУ ( tmpfsэто хорошо, потому что это позволяет вернуться к диску, если вам в некоторых случаях требуется ОЗУ) для хранения во время выполнения (и, возможно, сценарий initrd для копирования системы из хранилища на диск RAM при запуске).
Вы не сказали, является ли ваше устройство хранения SSD или HDD. Вот что я нашел работу для меня (в моем случае sdaэто HDD , установленный на /homeи sdbявляется SSD установлен на /).
Сначала оптимизируйте часть загрузки содержимого из хранилища в кэш:
Вот мои настройки для жесткого диска (убедитесь, что 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дает лучший ( самый низкий) общее время ожидания.
Для получения дополнительной информации об этих настройках см. Http://www.linux-mag.com/id/7572/ .
Теперь, когда мы настроили ядро для загрузки содержимого с диска в кеш с ощутимой производительностью, пришло время настроить поведение кеша:
В соответствии с тестами, которые я сделал, я бы вообще не стал настраивать чтение вперед blockdev. Настройки ядра по умолчанию в порядке.
Установите для системы предпочтение замены файловых данных по сравнению с кодом приложения (это не имеет значения, если у вас достаточно ОЗУ для хранения всей файловой системы и всего кода приложения и всей виртуальной памяти, выделенной приложениями в ОЗУ). Это уменьшает задержку для переключения между различными приложениями по сравнению с задержкой для доступа к большим файлам из одного приложения:
echo 15 > /proc/sys/vm/swappiness
Если вы предпочитаете хранить приложения почти всегда в оперативной памяти, вы можете установить это значение равным 1. Если вы установите это значение равным нулю, ядро вообще не поменяется местами, если только в этом нет крайней необходимости избегать OOM. Если у вас была ограниченная память и вы работали с большими файлами (например, редактирование HD-видео), то, возможно, имеет смысл установить это значение близко к 100.
Я сейчас (2017) предпочитаю вообще не иметь подкачки, если у вас достаточно оперативной памяти. Отсутствие свопинга обычно приводит к потере 200-1000 МБ ОЗУ на давно работающей настольной машине. Я готов пожертвовать этим, чтобы избежать задержки в худшем случае (замена кода приложения при заполнении ОЗУ). На практике это означает, что я предпочитаю обмен OOM Killer. Если вы разрешаете / нуждаетесь в обмене, вы также можете увеличить его /proc/sys/vm/watermark_scale_factor, чтобы избежать некоторой задержки. Я бы предложил значения от 100 до 500. Вы можете рассматривать эту настройку как торговую загрузку ЦП для более низкой задержки свопа. По умолчанию установлено значение 10, а максимально возможное значение равно 1000. Более высокое значение должно (в соответствии с документацией ядра ) привести к более высокой загрузке ЦП kswapdпроцессами и снижению общей задержки обмена.
Далее, скажите ядру, чтобы оно предпочитало хранить иерархию каталогов в памяти, а не содержимое файла, в случае, если необходимо освободить часть ОЗУ (опять же, если все умещается в ОЗУ, этот параметр ничего не делает):
echo 10 > /proc/sys/vm/vfs_cache_pressure
настройка vfs_cache_pressureнизкое значение имеет смысл, потому что в большинстве случаев ядру необходимо знать структуру каталогов, прежде чем оно сможет использовать содержимое файла из кэша, и слишком быстрая очистка кэша каталога сделает файловый кэш почти бесполезным. Если у вас много маленьких файлов, попробуйте пойти до 1 с этим параметром (моя система имеет около 150K 10-мегапиксельных фотографий и считается системой «много маленьких файлов»). Никогда не устанавливайте его в ноль, или структура каталогов всегда сохраняется в памяти, даже если системе не хватает памяти. Установка этого значения в большую имеет смысл, только если у вас есть только несколько больших файлов, которые постоянно перечитываются (опять же, пример HD-редактирования без достаточного объема ОЗУ был бы примером). Официальная документация по ядру говорит, что "
Исключение: если у вас действительно огромное количество файлов и каталогов, и вы редко касаетесь / читаете / выводите список всех файлов, значение которых vfs_cache_pressureпревышает 100, может быть целесообразным. Это применимо только в том случае, если у вас недостаточно ОЗУ и вы не можете сохранить всю структуру каталогов в ОЗУ и при этом все еще иметь достаточно ОЗУ для обычного файлового кэша и процессов (например, файловый сервер всей компании с большим количеством архивного содержимого). Если вы чувствуете, что вам нужно увеличить vfs_cache_pressureвыше 100, вы работаете без достаточного количества оперативной памяти. Увеличение vfs_cache_pressureможет помочь, но единственное реальное решение - получить больше оперативной памяти. Имея vfs_cache_pressureнабор для большого числа жертвует среднюю производительность для имеющих более стабильной работы в целом (то есть, вы можете избежать очень плохо наихудшего поведения случая , но иметь дело с худшей общей производительностью).
Наконец, скажите ядру использовать до 99% ОЗУ в качестве кэша для записи и дайте указание ядру использовать до 50% ОЗУ перед тем, как замедлить процесс записи (по умолчанию для dirty_background_ratiois 10). Предупреждение: лично я бы не стал этого делать, но вы утверждали, что у вас достаточно оперативной памяти и готовы потерять данные.
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
Если вы добавите все это /etc/rc.localи включите в конце следующее, все будет в кеше как можно скорее после загрузки (делайте это только в том случае, если ваша файловая система действительно помещается в ОЗУ):
(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действительно умещается в ОЗУ):
(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&