Почему процессы блокируются вводом-выводом в случае большой нагрузки на систему?

Я заметил это после перехода с Centos7 (3.10.0.1062 )на ядро ​​ElRepo -ml (5.11.6):Скорость обратной записи увеличилась примерно в 10 раз (с 2 Мб /sec до 20 Мбит/с ), но я использовал диск Samsung NVMe 400G со скоростью более 2000 Мбит/с, поэтому я ожидал большего. Затем я переключил монтирование ext4 на «nodelalloc,dioread _nolock», и теперь я получаю скорость обратной записи более 1500 Мбит/с. Так как у меня 512 Гб памяти и грязный _фоновый _коэффициент = 10, грязный _коэффициент = 20, при распаковке большой папки со многими средними (30 -50kb )файлами, грязный страницы увеличиваются до более чем 50 ГБ (со скоростью около 500 Мбит / с, ограниченной скоростью моего исходного жесткого диска RAID ), затем внезапно происходит обратная запись со скоростью 1500+ Мбит / с в течение примерно 35+ секунд. В течение более чем 35-секундного периода обратной записи задание tar падает до 0 % ЦП и 0 % операций ввода-вывода. Что-то в потоке ядра с обратной записью должно требовать блокировки, которая также требуется для системного вызова записи tar, и такого поведения определенно не было в Centos7 (3.10.0.1062 ).

Таким образом, поведение, описанное OP, реально, но, похоже, оно появилось недавно.

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

Пожалуйста, опубликуйте вывод:

find vm4 -type f | while read filename; do sudo filefrag "$filename" | egrep -v ": 1 extent|: 0 extents"; done | sort

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

Исходя из вашего отчета, показывающего ~40G свободной памяти (я знаю, что это не точное количество доступной памяти, но давайте подождем для быстрого и грязного исчисления Доступно 40G. И 12G, занятые буфером/кэшем, которые из-за отсутствия подробной информации мы допустим полны... грязных данных.

Поскольку отношение vm.dirty _по умолчанию равно 20% и 20% от 40G = 8G < 12G...

Я подозреваю, что ваша система работает с превышением предела, приказывающего процессу выполнить обратную запись самостоятельно. Другими словами выдача блокировка пишет.

Затем я бы проверил, каковы на самом деле ограничения системы:

$ sysctl -a | grep dirty

И если вы обнаружите, что соотношение vm.dirty _на самом деле соответствует значению по умолчанию, увеличьте его. (Вы можете легко увеличить значение до 80%, не беспокоясь. Если я правильно помню, Oracle рекомендует именно это значение.)

Пока вы это делаете, вы также можете понизить его компаньон (vm.dirty _background _ratio ), которое обычно по умолчанию равно 10. Система с низкой задержкой рекомендует минимально возможное значение (1 ), я лично установил для этого параметра значение 3. Это позволит демону обратной записи работать раньше, задерживая момент, когда кеш превысит предел, установленный коэффициентом грязных _.

Вы можете вносить временные изменения, выводя значения в соответствующую запись структуры каталогов /proc/sys/vm/. Чтобы сделать эти изменения постоянными (при перезагрузке ), вы можете отредактировать/etc/sysctl.conf

Это является непосредственной причиной блокировки процесса, а также причиной, по которой запись на устройство кажется настолько медленной, что кэш заполняется выше предела отношения грязных _:см. Artem -s -Ташкинов ответ.