Когда у вас есть LVM, у вас есть запись для планировщика в /sys/block
для ваших физических томов, а также для каждого отдельного логического тома и исходного устройства.
У нас есть система Debian 6 LTS x64, ядро 2.6.32 с гипервизором Xen 4.0 (аппаратный RAID1 3Ware 9650 SE). При запуске виртуальных машин на каждом логическом томе, на каком из них вам нужно настроить планировщик, если вы хотите повлиять на их планирование ОС? Если вы установите логический том на deadline
, будет ли это что-либо делать, когда физический объем установлен на cfq
? И если вы установите для логического тома крайний срок, будут ли эти крайние сроки соблюдаться, даже если диск замедляется из-за операций ввода-вывода на других LV, для которых установлено значение cfq
?
Вопрос связан с тем, что ввод-вывод на виртуальных машинах слишком сильно замедляет другие виртуальные машины. Все гости внутренне используют noop как планировщик.
Изменить: согласно этот, в среде с многолучевым распространением будет действовать только планировщик DM. Поэтому, если я хочу обрабатывать ввод-вывод между виртуальными машинами в deadline
Таким образом, я должен установить DM-путь физического тома (dm-1 в моем случае) на deadline
. Это правильно? Также есть планировщик для sdc, который является исходным блочным устройством моего dm-1. Почему бы не сделать этого на этом?
edit2: но потом кто-то говорит в комментариях, что dm-0/1 не имеет планировщика в новых ядрах:
famzah@VBox:~$ cat /sys/block/dm-0/queue/scheduler
none
В моей системе (Debian 6, ядро 2.6.32) у меня есть:
cat /sys/block/dm-1/queue/scheduler
noop anticipatory [deadline] cfq
Вопрос также в том, есть ли у меня настройка многопутевого режима? pvs
показывает:
# pvs
PV VG Fmt Attr PSize PFree
/dev/dm-0 universe lvm2 a- 5,41t 3,98t
/dev/dm-1 alternate-universe lvm2 a- 1,82t 1,18t
Но они были созданы с помощью / dev / sd [bc]. Означает ли это, что у меня есть несколько путей, хотя это стандартная установка LVM?
Главный вопрос, наверное, в том, надо ли мне устанавливать планировщик на sdc или dm-1? Если я использую iostat, я вижу много доступа к обоим:
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdc 0,00 0,00 13,02 25,36 902,71 735,56 42,68 0,08 2,17 0,73 2,79
dm-1 82,25 57,26 12,97 25,36 902,31 735,56 42,72 0,18 4,73 0,84 3,23
Итак, что есть что и кто здесь главный? Если это sdc, я могу вам сказать, что установка крайнего срока не влияет на производительность моих виртуальных машин. Глядя на разницу в столбцах «Объединенные запросы» (первые два), я бы сказал, что это dm-1, который контролирует планирование.
Итак, ответ оказался простым: лежащее в основе устройство. В новых ядрах нет только "none" /sys/block/*/queue/scheduler
когда нет планировщика для настройки.
Однако по неизвестной мне причине устройства на этом сервере созданы как многопутевые, поэтому я возился с планировщиком на /dev/sd[bc]
никогда ничего не делал в прошлом. Теперь я установил dm-1
и dm-0
к сроку с read_expire=100
и write_expire=1500
(гораздо более строгие, чем обычно), и результаты кажутся очень хорошими.
Этот график показывает влияние на задержку диска в виртуальной машине, вызванную другой виртуальной машиной с почасовой задачей:
Хорошо виден момент, когда я изменил параметры планировщика.
Хм, Debian ...
Что ж, я могу рассказать, как Redhat подходит к этому со своими настроенная структура. Есть профили для виртуального хоста и виртуального гостя. В описания профилей подробно описаны здесь, а в следующем отрывке показано, какие устройства затронуты. Планировщики устройств "dm- *" и "sdX" изменены.
# This is the I/O scheduler ktune will use. This will *not* override anything
# explicitly set on the kernel command line, nor will it change the scheduler
# for any block device that is using a non-default scheduler when ktune starts.
# You should probably leave this on "deadline", but "as", "cfq", and "noop" are
# also legal values. Comment this out to prevent ktune from changing I/O
# scheduler settings.
ELEVATOR="deadline"
# These are the devices, that should be tuned with the ELEVATOR
ELEVATOR_TUNE_DEVS="/sys/block/{sd,cciss,dm-,vd,zd}*/queue/scheduler"
Также см:
Настроенный эквивалент CentOS для Debian и Понимание рекомендованных настроенных профилей RedHat
как рекомендует vmware, лучше использовать планировщик noop, если ваш гость использует файл как виртуальный диск, таким образом ваш гость передает ввод-вывод на ваш хост напрямую, без реорганизации ввода-вывода дважды в вашем гостевом и физическом хосте