На самом деле, опция восстребованая, может в новых релизах все же донесли, хз

libvirt: iothreads for disk devices (I8ae0b5af) · Gerrit Code Review https://review.opendev.org/c/openstack/nova-specs/+/230968

Похоже тут люди заморачивались

И с 2015 года ничего не донесли???

Я бы початил в ирц на вашем месте с Алексом, он дельное скажет

Печалька

Вот хз, я почему то помню, что как раз с передачей тредов в вирш были какие то проблемы. И там выше писали, что с 2015 года особых подвижек нет

Но опять же, может я просто не в курсе, а копать нову глубоко - лениво.

Вот хз, я почему то помню, что как раз с передачей тредов в вирш были какие то проблемы. И там выше писали, что с 2015 года особых подвижек нет

Как раз на прошлой неделе ради эксперимента создал две виртуалки, Одну с virtio-scsi, Вторую с virtio. Бэкенд был один и тот же. Вторая работала на 25% быстрее первой

В смысле??? Я всегда думал что как раз scsi быстра аки ветер

А измеряли fio? Или как?

fio напрямую на /dev/sda и /dev/vda

Ну что штош.

e1000 это же зло?

e1000 это же зло?

Это не зло, а эмуляция сетевушки. Для ущербных гостевых систем в которых нет virtio драйверов. Типа стоковой винды или старых фрибсд.

Но да, медленно, печально.

Так говоришь как будто бывают нехитрожопые)

Завтра в Праге?

Майку застиранную надел вместо розовой рубашки и не побрился?)

Как раз на прошлой неделе ради эксперимента создал две виртуалки, Одну с virtio-scsi, Вторую с virtio. Бэкенд был один и тот же. Вторая работала на 25% быстрее первой

Шок-контент, обработка команд SCSI требует процессорного времени!!!

Всем добрый вечер! Можно ли заставить kolla подрубить хотя бы пару lvm бэкендов в конфигурации all-in-one? Надо отделить SSD от SATA на одном сервере. Создал я VG cinder-volumes-sata и cinder-volumes-ssd, в /etc/kolla/globals.d/cinder.yml их описал, но в cinder_volume_group нельзя список.

Всем добрый вечер! Можно ли заставить kolla подрубить хотя бы пару lvm бэкендов в конфигурации all-in-one? Надо отделить SSD от SATA на одном сервере. Создал я VG cinder-volumes-sata и cinder-volumes-ssd, в /etc/kolla/globals.d/cinder.yml их описал, но в cinder_volume_group нельзя список.

Можно, дописывай конфигурации в конец cinder.conf и они заведутся.

Можно, дописывай конфигурации в конец cinder.conf и они заведутся.

т.е в колле это задать нельзя, надо после установки "доработать напильником". Потом при реконфигурации проблем не будет?

Всем добрый вечер! Можно ли заставить kolla подрубить хотя бы пару lvm бэкендов в конфигурации all-in-one? Надо отделить SSD от SATA на одном сервере. Создал я VG cinder-volumes-sata и cinder-volumes-ssd, в /etc/kolla/globals.d/cinder.yml их описал, но в cinder_volume_group нельзя список.

Какой список? У каждого бекенда своя секция

Это не зло, а эмуляция сетевушки. Для ущербных гостевых систем в которых нет virtio драйверов. Типа стоковой винды или старых фрибсд.

так проще же указать vmxnet3 винда в него из коробки умеет

Какой список? У каждого бекенда своя секция

Как в этой секции для одной машины (inventory/all-in-one) указать свою VG?

т.е в колле это задать нельзя, надо после установки "доработать напильником". Потом при реконфигурации проблем не будет?

можно, кастомный конфиг положи, он смержит на этапе раскатки

можно, кастомный конфиг положи, он смержит на этапе раскатки

Понял, спасибо.

т.е в колле это задать нельзя, надо после установки "доработать напильником". Потом при реконфигурации проблем не будет?

Ничего допиливать не надо, пиши в конец конфига кастомконфигом

Ничего допиливать не надо, пиши в конец конфига кастомконфигом

то есть вы хотите сказать что threads для virtio-scsi можно доложить в конфиг либвирта? а как? а то я часа два пытался сделать это не руками, а через Nova, но получилось ((( подскажете?

то есть вы хотите сказать что threads для virtio-scsi можно доложить в конфиг либвирта? а как? а то я часа два пытался сделать это не руками, а через Nova, но получилось ((( подскажете?

А вроде нету, только блюпринт. https://blueprints.launchpad.net/nova/+spec/libvirt-add-support-for-virtio-scsi-multiqueue

А вроде нету, только блюпринт. https://blueprints.launchpad.net/nova/+spec/libvirt-add-support-for-virtio-scsi-multiqueue

спасибо, пропустил эту статью, при случае обязательно попробуем )))

спасибо, пропустил эту статью, при случае обязательно попробуем )))

Что попробуем?)

Это блюпринт, не реализовано.

ну вот (((

Я пропустил и лень листать. Чем virtio не подходит?

ну были мысли что можно что-то более быстрое чем virtio но похоже что нет

ну были мысли что можно что-то более быстрое чем virtio но похоже что нет

Про более быстрое обычныо думаешь когда точно понимаешь что в virtio узкое место)

"точно понимаешь" - понятие растяжимое )))

Про более быстрое обычныо думаешь когда точно понимаешь что в virtio узкое место)

Ну вот было у меня такое. Когда из хоста фио в три раза быстрее в локал диск писало, чем из вм

Ну вот было у меня такое. Когда из хоста фио в три раза быстрее в локал диск писало, чем из вм

А как ты определил что virtio виноват?

Ну вот было у меня такое. Когда из хоста фио в три раза быстрее в локал диск писало, чем из вм

да да да

А как ты определил что virtio виноват?

А кто?

Не виртио, а треды

А кто?

Бекэнд хранения виртуалок. Например, если у тебя диски вм лежат в файловой системе, то уже можно заподозрить что файловая система виновата. А если там raw+qcow2 оверлей, то в них может быть дело. Если LVM бекэнд, то он может быть виноват)

Вариантов то много.

Бекэнд хранения виртуалок. Например, если у тебя диски вм лежат в файловой системе, то уже можно заподозрить что файловая система виновата. А если там raw+qcow2 оверлей, то в них может быть дело. Если LVM бекэнд, то он может быть виноват)

Ну как бы нет. С фигали один и тот же диск фиошится по разному?

Ну как бы нет. С фигали один и тот же диск фиошится по разному?

Ну давай конкретную ситуацию поковыряем. У тебя диски в виде файлов лежат в фс хоста? Или какой бекэнд?

Я ж написал - локал стор

Я ж написал - локал стор

Ну так это и лвм может быть.

Ну ок. Вот смотри, если ты ничо не делал, то диск вируталки это raw + qcow2 оверлей. Запись вся идет, соответственно, в оверлей. И по-умолчанию используется thin provisioning. И когда меришь производительность нужно учитывать что тест на рандомную запись с хоста рандомно пишет в разные участки диска если это механика, ну или в разные блоки флеш памяти, как там решит контроллер. А когда тестишь изнутри вм, то у тебя ограничен набор секторов или флеш блоков, в которые будет происходить запись и уже одно это не даст полной производительности физического устройства. А еще ведь есть небольшой оверхэд от файловой системы хоста, оверхэд от qcow2 и уж в последнюю очередь тут играет роль virtio, я думаю)

А если еще вспомнить что у qemu-kvm процесса виртуалки ограничено число потоков, а сами потоки ядро распределяет по процессорным ядрам не самым оптимальным образом, то можно и еще небольшой оверхэдик накинуть)

Работа с дисками и достижение приемемой производительности это одна из самых сложных вещей, как мне кажется. Потому что слоев абстракции много, а предсказуемости не очень много в их работе. И нельзя просто взять и сказать "на хосте у меня 600к иопсов", а в виртуалке 170к, поэтому virtio не очень". Дело то мож совсем и не в нем.

Артемий лучше распишет, наверное и в куче мест поправит меня)

Ну тест про запись на сырое устройство) Но еще можно пофантазировать что на хосте один io планировщик, в ВМ другой и тоже хз каким это образом на производительности сказывается.

А если еще вспомнить что у qemu-kvm процесса виртуалки ограничено число потоков, а сами потоки ядро распределяет по процессорным ядрам не самым оптимальным образом, то можно и еще небольшой оверхэдик накинуть)

Так я про потоки с самого начала и писал. Никакого оверлея на raw нет, он тупо пишет в диск. Оверхед ФС - не серьезно, потому что фио тоже оверхедит в тоже самое. Разница, еще раз - три раза. Это МНОГО.

Так я про потоки с самого начала и писал. Никакого оверлея на raw нет, он тупо пишет в диск. Оверхед ФС - не серьезно, потому что фио тоже оверхедит в тоже самое. Разница, еще раз - три раза. Это МНОГО.

Есть) Оверлея не будет если ты images_type = flat поставил.

Так я про потоки с самого начала и писал. Никакого оверлея на raw нет, он тупо пишет в диск. Оверхед ФС - не серьезно, потому что фио тоже оверхедит в тоже самое. Разница, еще раз - три раза. Это МНОГО.

Остаешься при своем мнении?) Всё что я написал несерьезно, а что ты пишешь - серьезно?)

Остаешься при своем мнении?) Всё что я написал несерьезно, а что ты пишешь - серьезно?)

Походу ты очень хорошо за меня выдумываешь. Пообщайся сам с собой. :) Я написал про глупость что ФС дает оверхед только для виртуалки, а для фио такого не будет

Основной оверхэд происходит при выделении новых экстентов в хостовой фс, вероятнее всего.

А для фио этого не происходит? О как. :)

А для фио этого не происходит? О как. :)

Ты же говоришь что тест на сыром устройстве.

Сырое устройство на хосте это запись напрямую на диск. А для вируталки запись напрямую на её диск это фактически запись в файл в хостовой фс. Да еще и не выделенный целиком заранее.

Ты же говоришь что тест на сыром устройстве.

Мне написать грубо "научись читать"? :) Ну камон. Серьезно, какой то диалог сам с собой. Я написал: фио в тот же диск.

Берем файл и пишем. Что фио, что ВМ. Это ОДИН файл.

Мне написать грубо "научись читать"? :) Ну камон. Серьезно, какой то диалог сам с собой. Я написал: фио в тот же диск.

Файл в хостовой системе, так? ВМ как в него напрямую пишет?

Работа с дисками и достижение приемемой производительности это одна из самых сложных вещей, как мне кажется. Потому что слоев абстракции много, а предсказуемости не очень много в их работе. И нельзя просто взять и сказать "на хосте у меня 600к иопсов", а в виртуалке 170к, поэтому virtio не очень". Дело то мож совсем и не в нем.

Ой да все там просто. Хочешь производительности - соблюдайте простое правило: Не пиши в тонкий волюм (файл или лун - не имеет значения) и не используй CoW-решения Разница между thread i/O и native не слишком велика.

Я вообще склоняюсь к мнению что io=native и забросил в виртуалки сырого устройства то что доктор прописал

На тонких бакэндах не поможет. На на аллокпациях экстентов все потеряешь

Всегда была. Google://sparse+files

Сырое устройство на хосте это запись напрямую на диск. А для вируталки запись напрямую на её диск это фактически запись в файл в хостовой фс. Да еще и не выделенный целиком заранее.

Сильно зависит от кучи факторов. Например в синдере с лвм бакэндом это нифига не файл

А если бакэндом кукуха то да, забудь про производительность

Сильно зависит от кучи факторов. Например в синдере с лвм бакэндом это нифига не файл

Та не, я про локальные диски веду речь. Там же из вариантов raw\qcow2 с оверлеем, они же без оверлея и lvm.

А, ну и ploop, которым хз пользуется ли кто.

Разве что, в экзотических инсталляциях с виртуоззо)

Мне кажется, давно уже нет. Но до сих пор из новы не вычистили.

Интересно было бы узнать кто и почему использует до сих пор.

Та не, я про локальные диски веду речь. Там же из вариантов raw\qcow2 с оверлеем, они же без оверлея и lvm.

Ну юзай лвм с толстым провижнингом и будет тебе мегащастье