Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Расположение планировщиков ввода-вывода в упрощенной структуре ядра Linux.

Планировщик NOOP - это простейший планировщик ввода-вывода для ядра Linux . Этот планировщик был разработан Йенсом Аксбоэ .

Обзор [ править ]

Планировщик NOOP вставляет все входящие запросы ввода-вывода в простую очередь FIFO и реализует объединение запросов. Этот планировщик полезен, когда было определено, что хост не должен пытаться переупорядочить запросы на основе содержащихся в нем номеров секторов. Другими словами, планировщик предполагает, что хост не знает, как продуктивно изменять порядок запросов.

Есть (как правило) три основных ситуации, когда такая ситуация желательна:

  • Если планирование ввода-вывода будет обрабатываться на более низком уровне стека ввода-вывода. Примеры нижних уровней, которые могут обрабатывать планирование, включают блочные устройства, интеллектуальные контроллеры RAID, сетевое хранилище или внешний контроллер, такой как подсистема хранения, доступ к которой осуществляется через коммутируемую сеть хранения данных. [1] Поскольку запросы ввода-вывода потенциально перепланированы на более низком уровне, изменение последовательности операций ввода-вывода на уровне хоста использует время центрального процессора хоста для операций, которые будут просто отменены на более низком уровне, увеличивая задержку / уменьшая пропускную способность без каких-либо производственных причин.
  • Потому что точные детали положения сектора скрыты от хост-системы. Примером может служить RAID-контроллер, который не выполняет планирование самостоятельно. Несмотря на то, что хост имеет возможность переупорядочивать запросы, а RAID-контроллер - нет, хост-системе не хватает видимости, чтобы точно переупорядочить запросы, чтобы уменьшить время поиска. Поскольку хост не имеет возможности судить, лучше ли одна последовательность, чем другая, он не может оптимально реструктурировать активную очередь и, следовательно, должен передать ее устройству, которое (теоретически) более осведомлено о таких деталях.
  • Потому что движение головки чтения / записи недостаточно влияет на производительность приложения, чтобы оправдать накладные расходы на переупорядочение. Обычно это происходит с невращающимися носителями, такими как флэш-накопители или твердотельные накопители (SSD).

Однако NOOP не обязательно является предпочтительным планировщиком ввода-вывода для описанных выше сценариев. Как и при любой настройке производительности, все рекомендации будут основаны на наблюдаемых моделях рабочей нагрузки (что подрывает способность создавать упрощенные практические правила). Если есть конкуренция за доступную пропускную способность ввода-вывода от других приложений, все же возможно, что другие планировщики будут генерировать более высокую производительность благодаря более разумному разделению этой полосы пропускания для приложений, которые считаются наиболее важными. Например, запуск сервера каталогов LDAP может выиграть от предпочтения крайнего срока чтения и гарантий задержки. В то же время пользователь с настольной системой, на которой запущено множество различных приложений, может захотеть получить доступ к CFQ.настраиваемые параметры или его способность устанавливать приоритет пропускной способности для определенных приложений над другими ( ionice ).

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

Ядро Linux также предоставляет параметр nomerges sysfs как конфигурацию, не зависящую от планировщика, что позволяет отключить логику слияния запросов блочного уровня либо полностью, либо только для более сложных попыток слияния. [2] Это снижает потребность в планировщике NOOP, поскольку накладные расходы большинства планировщиков ввода-вывода связаны с их попытками определить местонахождение соседних секторов в очереди запросов, чтобы объединить их. Однако большинство рабочих нагрузок ввода-вывода выигрывают от определенного уровня слияния запросов даже в быстрых хранилищах с малой задержкой, таких как твердотельные накопители. [3] [4]

См. Также [ править ]

Ссылки [ править ]

  1. ^ «Выбор планировщика ввода-вывода для Red Hat Enterprise Linux 4 и ядра 2.6» . Красная шляпа. Архивировано из оригинала на 2007-08-27 . Проверено 10 августа 2007 .
  2. ^ «Документация / блок / очередь-sysfs.txt» . Документация ядра Linux . kernel.org . 1 декабря 2014 . Проверено 14 декабря 2014 года .
  3. ^ «6.4.3. Noop (документация по Red Hat Enterprise Linux 6)» . Красная шляпа . 8 октября 2014 . Проверено 14 декабря 2014 года .
  4. ^ Пол Querna (15 августа 2014). «Сконфигурируйте флэш-накопители в экземплярах с высоким уровнем ввода-вывода как диски данных» . Rackspace . Проверено 15 декабря 2014 года .

Внешние ссылки [ править ]

  • Понимание и оптимизация дискового ввода-вывода
  • Оценка производительности планировщиков ввода-вывода Linux 2.6 в зависимости от рабочей нагрузки
  • Лучшие практики для виртуальной машины на основе ядра (предоставляет общую информацию о планировщиках ввода-вывода)
  • Тестирование планировщиков ввода-вывода Linux - упреждающее против CFQ против крайнего срока против отсутствия