Нооп-планировщик
 | Эта статья нуждается в дополнительных цитатах для проверки . ( декабрь 2014 г. ) |
Планировщик NOOP — это самый простой планировщик ввода-вывода для ядра Linux . Этот планировщик разработал Йенс Аксбо .
Обзор
[ редактировать ]Планировщик NOOP помещает все входящие запросы ввода-вывода в простую очередь FIFO и реализует объединение запросов. Этот планировщик полезен, когда было определено, что хост не должен пытаться изменить порядок запросов на основе содержащихся в нем номеров секторов. Другими словами, планировщик предполагает, что хост не знает, как продуктивно переупорядочить запросы.
Есть (как правило) три основные ситуации, когда такая ситуация желательна:
- Если планирование ввода-вывода будет выполняться на нижнем уровне стека ввода-вывода. Примеры нижних уровней, которые могут управлять планированием, включают блочные устройства, интеллектуальные RAID-контроллеры, сетевое хранилище или внешний контроллер, такой как подсистема хранения, доступ к которому осуществляется через коммутируемую сеть хранения данных. [1] Поскольку запросы ввода-вывода потенциально перепланируются на нижнем уровне, повторное упорядочение операций ввода-вывода на уровне хоста использует время процессора хоста для операций, которые будут просто отменены на более низком уровне, увеличивая задержку или уменьшая пропускную способность без какой-либо продуктивной причины.
- Потому что точные сведения о положении сектора скрыты от хост-системы. Примером может служить RAID-контроллер, который самостоятельно не выполняет планирование. Несмотря на то, что хост имеет возможность изменять порядок запросов, а RAID-контроллер — нет, хост-системе не хватает возможности точно изменить порядок запросов, чтобы сократить время поиска. Поскольку хост не имеет возможности оценить, лучше ли одна последовательность, чем другая, он не может оптимально реструктурировать активную очередь и, следовательно, должен передать ее на устройство, которое (теоретически) лучше осведомлено о таких деталях.
- Потому что движение головки чтения/записи не влияет на производительность приложения настолько, чтобы оправдать накладные расходы на переупорядочение. Обычно это касается невращающихся носителей, таких как флэш-накопители или твердотельные накопители (SSD).
Однако NOOP не обязательно является предпочтительным планировщиком ввода-вывода для описанных выше сценариев. Как это обычно бывает при настройке производительности, все рекомендации должны основываться на наблюдаемых закономерностях рабочей нагрузки (подрывая способность создавать упрощенные эмпирические правила). Если существует конкуренция за доступную пропускную способность ввода-вывода со стороны других приложений, все равно возможно, что другие планировщики будут обеспечивать более высокую производительность за счет более разумного распределения этой пропускной способности для приложений, которые считаются наиболее важными. Например, при запуске сервера каталогов LDAP можно воспользоваться преимуществом чтения по крайнему сроку и гарантиями задержки. В то же время пользователь настольной системы, на которой работает множество различных приложений, может захотеть иметь доступ к ionice настройкам CFQ или его возможности определять приоритет полосы пропускания для определенных приложений над другими ( ) .
Если между приложениями нет конфликтов, то от выбора планировщика для трех перечисленных выше сценариев пользы практически нет. Это происходит из-за невозможности снизить приоритет операций одной рабочей нагрузки таким образом, чтобы сделать дополнительную мощность доступной для другой рабочей нагрузки. Другими словами, если пути ввода-вывода не перегружены и запросы ко всем рабочим нагрузкам не вызывают необоснованного смещения головок накопителей (о чем знает операционная система), преимущество установки приоритета одной рабочей нагрузки может создать ситуацию где время ЦП, затраченное на планирование ввода-вывода, тратится впустую вместо того, чтобы обеспечить желаемые преимущества.
Ядро Linux также предоставляет nomerges параметр sysfs как конфигурация, не зависящая от планировщика, что позволяет полностью отключить логику слияния запросов уровня блока или только для более сложных попыток слияния. [2] Это снижает потребность в планировщике NOOP, поскольку накладные расходы большинства планировщиков ввода-вывода связаны с их попытками найти соседние сектора в очереди запросов, чтобы объединить их. Однако большинство рабочих нагрузок ввода-вывода выигрывают от определенного уровня слияния запросов, даже в быстродействующих хранилищах с малой задержкой, таких как твердотельные накопители. [3] [4]
См. также
[ редактировать ]
- Упреждающее планирование
- Планировщик сроков
- CFQ Планировщик
Ссылки
[ редактировать ]- ^ «Выбор планировщика ввода-вывода для Red Hat Enterprise Linux 4 и ядра 2.6» . Красная шляпа. Архивировано из оригинала 27 августа 2007 г. Проверено 10 августа 2007 г.
- ^ «Документация/блок/очередь-sysfs.txt» . Документация по ядру Linux . ядро.орг . 1 декабря 2014 года . Проверено 14 декабря 2014 г.
- ^ «6.4.3. Noop (документация Red Hat Enterprise Linux 6)» . Красная шляпа . 8 октября 2014 года . Проверено 14 декабря 2014 г.
- ^ Пол Керна (15 августа 2014 г.). «Настройте флэш-накопители в экземплярах с высоким уровнем ввода-вывода как диски с данными» . Рэкспейс . Проверено 15 декабря 2014 г.
Внешние ссылки
[ редактировать ]- Понимание и оптимизация дискового ввода-вывода
- Оценка производительности планировщиков ввода-вывода Linux 2.6 в зависимости от рабочей нагрузки
- Рекомендации по использованию виртуальной машины на основе ядра (предоставляет общую информацию о планировщиках ввода-вывода)
- Планировщики ввода-вывода Linux протестированы: упреждающий, CFQ, крайний срок и noop
