Руками это можно сделать записав
noop в /sys/block/sda/queue/scheduler, но проблема в том, что в тестовый сервер собран на базе простого десктопного железа но с дополнительными SATA контроллерами на шине PCI-E x1. Системный диск и вовсе IDE.Один из способов решить проблему - задать
elevator=noop в параметрах ядра, но тогда придется руками найти системный жесткий диск и вернуть ему cfq в качестве планировщика. Но мне больше нравится идея оставить cfq по-умолчанию, а для жестких дисков с NCQ включить noop в из скрипта при загрузке системы.
$ cat /root/bin/noop4ncq.sh
#!/bin/bash
for _blkdev in `ls -1d /sys/block/*`
do
# Check if block device has support for NOOP IO scheduler
if [ -e "$_blkdev/queue/scheduler" ]; then
if `grep -q noop "$_blkdev/queue/scheduler"`; then
if [ ! -e "$_blkdev/device/queue_depth" ]; then
continue
fi
if [ `cat "$_blkdev/device/queue_depth"` -gt 1 ]; then
echo -n "Selecting NOOP I/O scheduler for $_blkdev: "
echo noop >"$_blkdev/queue/scheduler" 2>/dev/null && echo OK || echo FAIL
else
continue
fi
else
continue
fi
fi
done
Из скрипта видно, что noop включается не для всех блочных устройств, а только для тех, у которых queue depth > 1. Это связано с тем, что для правильной планирования очереди запросов на аппаратном уровне недостаточно иметь только SATA II жесткий диск. Еще нужна поддержка NCQ в SATA контроллере и операционной системе хоста.
Осталось прописать вызов
/root/bin/noop4ncq.sh в /etc/rc.local и все.UPDATE: Альтернативное решение с использованием UDEV описано тут.
А что показали результаты тестирования ?
ОтветитьУдалитьУ меня RAID-0 + LVM2. Тесты в fio показали разницу в 0-1% между CFQ и NOOP. Я еще буду смотреть детальнее, но получается что переключение планировщика при работе с блочными устройствами напрямую не имеет разницы.
Удалить