Я запускаю эту команду на сервере Debian с SSD-дисками, настроенными как RAID 1:
ionice -c 3 find . -type f -amin -1440 -mmin +1441 -not -path custom/ -print0
по пути, который содержит более 1,7 млн файлов и каталогов.
Я заметил, что каждый раз, когда я запускаю эту команду, нагрузка на сервер резко возрастает, и мне было интересно, можно ли как-нибудь задушить find скорость, поэтому он не будет создавать такие высокие нагрузки.
Также мне было интересно, есть ли здесь параметры, специфичные для SSD, чтобы уменьшить нагрузку на find
Это сводится к настройке файловой системы и procfs. То, что вы объясняете как «высокую» нагрузку, - это ситуация, когда другие нормальные процессы в системе не могут читать и вынуждены ждать.
Ситуация характеризуется
Использование планировщика noop здесь не помогает, поскольку noop - это простой планировщик FIFO, и он не может помочь вам внести больше справедливости в игру с доступом к диску. Поэтому я предлагаю использовать планировщик сроков.
Идея планировщика крайних сроков состоит в том, чтобы спроектировать окончательный крайний срок для определенной операции ввода-вывода диска и при этом поддерживать две простые очереди - одну для чтения и одну для записи; вы можете настроить сродство чтения к записи и время, в течение которого вы можете допустить, чтобы некоторое чтение / запись оставалось в очереди, прежде чем текущая операция будет остановлена и будет обслуживаться задача ввода-вывода с почти истекшим сроком действия.
Кроме того, вы хотите, чтобы в ОЗУ было много записей в каталоге и файловых индексных дескрипторов. Этот вид кеша значительно экономит дисковый ввод-вывод при просмотре такой большой структуры каталогов / файлов.
grep ^Slab /proc/meminfo
Это покажет вам, сколько памяти полностью выделено для записи в каталог и файлового кеша. Подробности о том, что и как эта память Slab разделяется / используется, можно найти в
/proc/slabinfo
Вы можете запустить slabtop чтобы получить интерактивную статистику использования.
В конечном итоге, если вы решите увеличить этот вид кеша, вы захотите уменьшить ценность
sysctl -w vm.vfs_cache_pressure = 20
По умолчанию установлено значение 100, что происходит в ситуациях, когда системе не хватает памяти, пытаясь значительно уменьшить объем памяти, используемый для кэширования d_entry файловых inodes по сравнению с кешем страницы (например, кеш данных файла / программы в ОЗУ), уменьшая значение, которое вы предпочтет сохранить эти d_entry / file inode кешем и, следовательно, потребует меньше операций чтения для повторного чтения тех же данных с диска, если они были удалены из кеша из-за нехватки памяти.
Кроме того, чтобы улучшить ваши возможности чтения с диска, я бы рекомендовал увеличить опережающее чтение.
blockdev --getra / dev / sda
blockdev --setra 2048 / dev / sda
Это должно помочь вам получить дополнительные IOPS, особенно если ваша система выполняет больше операций чтения, чем записи. (чтобы убедиться, что iostat может помочь; первая строка всегда является совокупным использованием, так как время загрузки, поэтому легко определить коэффициенты из этого)
Следующее, что я бы рассмотрел, это уменьшение размера - это nr_requests
эхо 32> / системный / блок / sda / очередь / nr_requests
Таким образом вы получите более короткие пакеты, что позволит увеличить задержку за счет некоторой пропускной способности, которую мы получили. Системы с множеством процессов выиграют от этого, поскольку одному процессу будет сложнее доминировать в очереди ввода-вывода, в то время как другие будут голодать.
Подробнее об этом также можно прочитать здесь: настройка аппаратного RAID-контроллера
Другой случай, когда у вас могут быть высокие нагрузки, - это если ваша обычная системная деятельность прерывается каким-то прерывистым большим пакетом записи, например загрузка больших файлов, копирование, распаковка. Записи также могут легко перенасыщать дисковый ввод-вывод, и для борьбы с этим я бы рекомендовал несколько снизить настройку.
vm.dirty_background_ratio
vm.dirty_ratio
Осторожно, не опускайся слишком низко. Чтобы получить представление, вы можете использовать atop инструмент и проверьте статистику диска, где вы можете увидеть, сколько грязных данных обычно находится в памяти; насколько процессы извлекают выгоду из грязной памяти (столбец WCANCL в статистике диска) и несколько превышают эти показатели использования.
Это поможет задействовать механизм ядра для регулирования обратной записи, который пытается замедлить процессы, которые влияют на ввод-вывод системы, выполняя тяжелые записи. для получения дополнительной информации проверьте регулирование обратной записи
Нет смысла стараться любой ценой поддерживать низкую нагрузку. Важно то, что ваш процесс отступает, если что-то более важное требует использования ресурсов, предлагаемых вашей системой.
ionice и nice / renice может использоваться для уменьшения приоритета, чтобы он работал только тогда, когда система в противном случае простаивает.