Почему системы замедляются при выполнении массивной записи на диск?

Я хочу знать, почему системы замедляются при записи массовых данных на диск.

Я думаю, что для того, чтобы система стала медленной, должна быть некоторая проблема с процессором. Но запись ограничена только I / O.

Имеются ли аппаратные прерывания при записи данных? Если это так, это может быть из-за прерываний, что процессор всегда переключает контекст.

Основная причина заключается в том, что обычно: ввод / вывод намного медленнее, чем ЦП / ОЗУ. Даже если процессы, выполняющие операции ввода-вывода, используют DMA (который разгружает ЦП), в какой-то момент им, вероятно, придется ждать завершения своих запросов.

В наиболее обычном случае с жестким диском просто добавьте несколько приложений, пытающихся получить доступ к файлам, разбросанным по всему диску, и вы сможете приготовить себе кофе (чай, что угодно). С твердотельными накопителями ситуация улучшается, но даже с твердотельным накопителем, чья пропускная способность измеряется в сотнях МБ / с на SATA (по сравнению с десятками МБ / с на жестком диске с вращающейся пластиной) и действительно незначительное время поиска (по сравнению с миллисекундами для спин-тарелка) - может стать узким местом.

Проблема, насколько я понимаю, заключается не только в самих переносах данных, но и в необходимых издержках - ввод-вывод контролируется ядром, но редко происходит без пространства пользователя. Таким образом, может быть много переключений контекста, только от приложений, ожидающих ввода-вывода, чтобы проверить, происходит ли что-то (конечно, зависит от реализации). В случае переноса диска вполне может быть несколько потоков ядра, конкурирующих за ресурсы или ожидающих занятости (что иногда является подходящей стратегией). Помните, например, что копирование данных из одного раздела в другой требует современной файловой системы: выяснить, где находятся исходные данные, прочитать их, выделить место в целевой файловой системе, записать метаданные, записать данные, повторить до конца.

И если в какой-то момент ваша система начинает обмениваться (что обычно имеет более высокий приоритет, чем обычный ввод / вывод), авария завершается.

РЕДАКТИРОВАТЬ : После разговора с некоторыми разработчиками ядра Linux ситуация стала немного яснее. Основной проблемой является планировщик ввода / вывода, который не имеет большого представления о том, какой ввод / вывод следует расставить по приоритетам. Следовательно, любой пользовательский ввод и последующий графический вывод делят очередь с дисковой / сетевой активностью. Вследствие этого может также случиться так, что он может выбросить кэшированные данные процесса из кэша страниц (например, загруженные библиотеки), когда он решит, что может использовать кэш страниц более эффективно при других операциях ввода-вывода. Это, конечно, означает, что, как только этот код необходимо будет запустить снова, его придется извлекать снова - с диска, который уже может быть под большой нагрузкой.

Тем не менее, что касается ядра Linux, многие из этих проблем были исправлены в последнее время (проблема была известна), так что, скажем, 4.4.x или 4.5.x должны вести себя лучше, чем раньше, и о проблемах следует сообщать (обычно люди ядра счастливы, когда кто-то хочет помочь сообщением об ошибках и тестированием).

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

Вы можете влиять на влияние тяжелых задач ввода-вывода с помощью ionice. Если вы поместите их в idleприоритет, задержка для других задач может все еще увеличиться, но не выше минимума. Задача ввода / вывода немедленно прерывается, если другая (не простаивающая) задача должна выполнить ввод / вывод. Если вы используете планировщик, который поддерживает эти настройки.

См. Выбор планировщика ввода-вывода Linux