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

Всякий раз, когда существует высокий дисковый ввод / вывод, система имеет тенденцию быть намного медленнее и менее отзывчивой, чем обычно. Каков прогресс в ядре Linux в этом отношении? Активно ли решается эта проблема?

Я думаю, что по большей части это было решено. Моя производительность при тяжелых операциях ввода-вывода улучшилась в 2.6.36, и я ожидаю, что она улучшится в 2.6.37. Смотрите эти статьи phoronix .

Wu Fengguang и KOSAKI Motohiro на этой неделе опубликовали исправления, которые, по их мнению, решат некоторые из этих проблем с отзывчивостью, для которых они называют «система перестает отвечать под давлением памяти и большим количеством грязных страниц / страниц с обратной записью». Андреас Мор, один из пользователей, который сообщил об этой проблеме в LKML и протестировал два исправления, которые были применены к ядру vmscan, сообщил об успехе. Проблема Андреаса заключалась в том, что система полностью перестала отвечать (и переключение на VT заняло более 20 секунд) при создании файловой системы EXT4, когда твердотельный накопитель был подключен через USB 1.1. На его системе при записи 300M из файла / dev / zero проблема была еще хуже.

Вот прямая ссылка на ошибку

Также из Фороникса

К счастью, по результатам нашего тестирования и сообщений других пользователей Linux, желающих исправить эту проблему, относительно небольшие опубликованные исправления vmscan, похоже, лучше решают эту проблему. Пользовательский интерфейс (в нашем случае GNOME) по-прежнему не является на 100% плавным, если система поддерживает подавляющее количество дисковой активности, но он, безусловно, намного лучше, чем раньше, и то, что даже сейчас можно найти в ядре Linux 2.6.35.

Также есть объявление о выпуске Phoronix 2.6.36

Кажется, что блочные барьеры исчезают, и это также должно помочь производительности.

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

Есть также эта статья LWN о честном планировании ввода / вывода

Я бы сказал, что IO пробудился как грандиозное событие о времени выхода ext4 в 2.6.28. Следующие ссылки относятся к выпускам ядра ядра Linux. Вам следует ознакомиться с разделами «Блок» и «Файловые системы». Это, конечно, может быть несправедливым настроением, или как раз в то время, когда я начал наблюдать за развитием FS, я уверен, что он улучшался все время, но я чувствую, что некоторые из проблем ext4 'заставили людей пристально смотреть на стек ввода-вывода, или возможно, они ожидали, что ext4 решит все проблемы с производительностью, а затем, когда этого не произошло, они поняли, что должны искать проблемы в других местах.

2.6.28 , 2.6.29 , 2.6.30 , 2.6.31 , 2.6.32 , 2.6.33 , 2.6.34 , 2.6.35 , 2.6.36 , 2.6.37