Выбор Планировщика ввода-вывода Linux
Типичным решением является исключение.
Логика заключается в следующем: конструктор - это метод, который преобразует кусок памяти в допустимый объект. Либо это удается (обычно завершается), и у вас есть действующий объект, либо вам нужен какой-то неузнаваемый индикатор проблемы. Исключения - единственный способ сделать проблему невосполнимой в C ++.
2 ответа
Как описано в /usr/src/linux/Documentation/block/switching-sched.txt , планировщик ввода-вывода на любом конкретном блочном устройстве можно изменить на время выполнения. Может быть некоторая задержка, так как все запросы предыдущего планировщика сбрасываются перед использованием нового планировщика, но ее можно без проблем изменить, даже когда устройство интенсивно используется.
# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq
В идеале, должен быть один планировщик для удовлетворения все нужды. Кажется, его еще нет. Ядру часто не хватает знаний, чтобы выбрать лучший планировщик для вашей рабочей нагрузки:
noopчасто является лучшим выбором для блочных устройств с поддержкой памяти (например, ramdisks) и другие невращающиеся носители (флэш), где попытка перепланирования ввода-вывода является пустой тратой ресурсовкрайний срок- это упрощенный планировщик, который пытается установить жесткое ограничение задержкиcfqпытается поддерживать общесистемную справедливость пропускной способности ввода-вывода
По умолчанию долгое время было упреждающим , и он подвергся большой настройке, но был удален в 2.6.33 ] (начало 2010 г.). cfq некоторое время назад стал стандартом по умолчанию, поскольку его производительность разумна, а справедливость - хорошая цель для многопользовательских систем (и даже для однопользовательских рабочих столов). Для некоторых сценариев базы данных часто используются в качестве примеров, поскольку они, как правило, уже имеют свои собственные специфические схемы планирования и доступа,
Цель того, чтобы ядро поддерживала разные версии, состоит в том, чтобы вы могли опробовать их без перезагрузки; затем вы можете запускать тестовые рабочие нагрузки через систему, измерять производительность, а затем делать это стандартным для вашего приложения.
На современном оборудовании серверного уровня только noop-приложение может оказаться полезным. Остальные в моих тестах кажутся медленнее.