Я пытаюсь построить эксперимент, чтобы измерить эффект ионизации. Я бы хотел (за еще один ответ на serverfault) вызывают достаточно частые операции ввода-вывода, так что достаточно "ловкий" процесс лишается каких-либо операций ввода-вывода.
На основе еще один ответ на serverfault, Я думаю, мне нужно вызывать по крайней мере одну фактическую операцию ввода-вывода для обычного устройства, запланированного cfq, каждые 250 мс. Я думал написать простую программу, в которой есть цикл,
fsync() (для принудительного выполнения определенной операции ввода-вывода),usleep() чтобы отложить настраиваемое количество времениlseek() чтобы обрезать файл (чтобы я не заполнял файловую систему)Затем я запускаю один экземпляр программы, используя ionice -c3 (праздный класс планирования) для одного файла на общем устройстве. Я одновременно запускаю разные экземпляры со значением по умолчанию (лучшее усилие) класс планирования, определяющий другой файл на общем устройстве (изменяя значения задержки).
Моя гипотеза заключалась в том, что для значений задержки 250 мс или более в процессе «максимальных усилий» я буду видеть прогресс, достигнутый в «простаивающем» процессе; для значений менее 250 мс я бы практически не заметил прогресса в "холостом" процессе.
Мое наблюдение заключалось в том, что не было никакой разницы в производительности двух процессов; они оба добились одинакового прогресса. На всякий случай (в случае, если настенные часы показывают, что процесс с максимальным усилием выполнял ввод-вывод намного быстрее, чем каждые 250 мс), я запустил несколько одновременных экземпляров процесса с максимальным усилием, указав no (ноль) задержка. Тем не менее, я не заметил разницы в производительности между процессами в двух классах планирования.
На всякий случай перепроверил класс планировщика:
$ cat /sys/block/xvda/queue/scheduler
noop anticipatory deadline [cfq]
Что мне не хватает в работе планировщика cfq?
Если это важно, это ядро 2.6.18.
Я бы попробовал измерить эффект с помощью генератора нагрузки, например stress -i n или stress -d n, где «n» - количество процессов. Запустите это в одном окне. Пытаться nmon или iostat в другом и попробуйте типичный процесс приложения на том же блочном устройстве. Посмотрите, как меняется время обслуживания в iostat с различными настройками ionice (или проверьте ответ из вашего приложения).
Что касается cfq, казалось, что на протяжении всего жизненного цикла RHEL5 (2.6.18) происходили изменения. На моих серверах приложений это было достаточно заметно, и мне пришлось перейти на noop и deadline лифты из-за проблем с конкуренцией.