Руками это можно сделать записав
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. Я еще буду смотреть детальнее, но получается что переключение планировщика при работе с блочными устройствами напрямую не имеет разницы.
Удалить