У меня установлен Citrix XenServer 6.1 на сервере HP (1x Intel Xeon E5630 @ 2,53 ГГц (4 ядра, 8 потоков, ОЗУ: 752 МБ для dom0 и 55286 МБ для гостей). Сервер имеет 2 зеркальных диска scsi и используется для разработки / тестирование.
Хост запускает 5 гостей, которых я включал или выключал во время тестов. Большинство тестов производительности дали плохие результаты. Но я бы хотел настроить Xen: например, «dd if = / dev / zero ...» дает 130 МБ / с на хосте, но только 75 МБ / с на одиночном госте.
Если я запустил dd if=/dev/urandom на гостевой системе CPU загружен, и я получаю 7 МБ / с.
Через tune-vcpus, Мне удалось отдать 8 виртуальных ЦП на dom0, и у меня стало меньше перфомансов. По умолчанию установлено 4 виртуальных ЦП, и я хотел бы предоставить dom0 только 1 виртуальный ЦП, но это не работает.
Вот что я пробовал:
/etc/sysconfig/tunes-vcpus > NR_DOMAIN0_VCPUS = 1 и MAX_NR_DOMAIN0_VCPUS = 1/etc/init.d/tune-vcpus начало минЯ тоже пробовал
/opt/xensource/libexec/xen-cmdline -set-dom0 blkbk.reqs=256
чтобы получить больше производительности от хранилища, он ничего не меняет.
И я включил Qos на VBD и отдал высший приоритет тому, на котором я проводил свои тесты.
После всего этого я не получаю никакого прироста в производительности ввода-вывода. Есть ли что-нибудь еще?
Похоже, вы имеете в виду конкретно пропускную способность хранилища от гостя. Это только один из многих показателей производительности. Пропускная способность ввода-вывода зависит от пропускная способность и задержка. Это означает, что для достижения высокой пропускной способности вам необходимо минимизировать задержку и максимизировать пропускную способность (т.е. иметь много данных, передаваемых в любое время, а запросы на эти данные обрабатываются как можно быстрее).
Когда вы находитесь в виртуализированной среде, вы неизбежно добавляете задержку для обслуживания ваших запросов. Это означает, что domU будет очень сложно соответствовать пропускной способности, которую вы видите в dom0. Будем надеяться, что это влияние будет минимизировано, если позволить большему количеству данных перемещаться в любое время (либо за счет большого количества виртуальных машин, выполняющих ввод-вывод, либо за счет наличия достаточно больших запросов).
Учитывая ваше оборудование и скорость, о которой вы говорите (~ 150 МБ / с), я был бы очень удивлен, если бы вы не смогли увидеть аналогичную пропускную способность у гостя с учетом вашего dd имеет правильные параметры.
Попробуйте это с вашего "dom0" и с вашего "domU" (команда ниже запишет 500 МБ данных в delete.me:
dd if=/dev/zero of=delete.me bs=1M count=500 oflag=direct
В oflag=direct убедитесь, что эти записи будут обходить буферные кеши виртуальных машин (dom0 и domU).
Кроме того, обратитесь к следующему документу, чтобы лучше понять, как XenServer 6.1.0 реализует виртуализированное хранилище, и любые его последствия для производительности (включая рекомендации по настройке количества виртуальных ЦП и закреплению):
Одна вещь, которую вы можете попробовать добавить, - это переключить планировщик io в vm на дедлайн и фактически отключить там слияния io. Это должно уменьшить задержку io в целом и может лучше работать с кольцевой структурой ввода-вывода Xen.
echo 1 > /sys/block/$dev/queue/nomerges
Мои рассуждения и опыт заключаются в том, что блочный код Linux на самом деле не умен, но думает, что это так. Таким образом, он попытается в идеале объединить все запросы ввода-вывода в один, прежде чем передавать их драйверу диска. В случае Xen следующим действием будет их разделение, чтобы они поместились в кольцевом буфере. Затем они находятся в dom0, и драйвер диска там находится в гораздо более удобном положении, чтобы узнать, что нужно объединить, поскольку для выравнивания не нужно брать какие-то отдельные знания виртуальных машин.
Если это не поможет, отмените изменение, но я бы посмотрел именно там, когда все остальное уже было испробовано.
Возможно, ваш сервер давно заброшен, но я все равно помогу кому-то другому.
Вы можете попробовать найти хорошее значение для max_sectors_kb. По умолчанию он установлен на 512 или 1024. Например, вы можете установить его на 128 и снова протестировать (dom0, а также domU).
echo 128 > /sys/block/[your blockdevice]/queue/max_sectors_kb
Этот параметр не является постоянным. Поместите запись в /etc/rc.local, чтобы установить ее при запуске.
Пожалуйста, опубликуйте свои результаты.