proxmox ввод/вывод

А если пробросить pci raid контроллер через vtd напрямую в гостя..?

синтетические тесты показывают потерю производительности примерно на 40%

Не хочу показаться занудой, но, ИМХО, это адекватная потеря производительности. Тем более для Windows, которая не особо предназначена для запуска под kvm. Полагаю, нужно смотреть в сторону VMware/Hyper-V.

Ну и опять же, 100k iops, этого не достаточно для базы?

VMware - дорого (ферма, 15 серверов+постоянный рост) Hyper-V - спасибо, но пережили.

Я думаю решение есть…

И что это даст?:)

Я так понимаю, что vt-d должен дать полную скорость, так-как выкидываем прослойку virtio. Ну хотя бы для теста попробовать. Но, это будет монопольный доступ, конечно.

Это велосипед с квадратными колесами.:)

Подожду еще комментариев по существу.

Это стандартное решение. Первый раз видишь виртуализацию?

Можно попробовать u_ring/native, точнее даже нужно было использовать в первую очередь. Вообще очень странные цифры.

а сервер БД каиой? MS SQL? запусти на linux-он же на нем запускается

Мы тут обсуждаем не выбор решения, а причину возникновения.

А можно поставить на хост винду и забыть про все это. ps совет не принят, ибо чушь!

Аргументы будут, или ты сюда зашёл потроллить?

Покажи конфиг виртуалки. Какими средствами сделан RAID?

это даст нужные тебе иопсы

Зря тратишь силы

This

Основной вопрос, в случае ТС я бы в реальности ставил: а насколько в реальности эти самые iops нужны. :) У меня вполне себе SAP бегает на proxmox, но с должным кол-вом ОЗУ, иначе, мои SATA enterprise SSD оно клало на лопатки по вводу-выводу линейному тупо, без всяких iops. 100k iops, ИМХО, хватит всем.

:) Да всем хочется найти серебрянную пулю. Полагаю, в случае с proxmox, мы не платим за софт, но платим производительностью. По-этому, по моему скромному мнению, в случае ТС, если прямо реально нужны столь огромные iops, то стоит сделать сравнительный тест: Hyper-V, promox+vt-d, VMware. После чего уже принимать осознанное решение.

может для него разница между 100к и 170к критична =)

смысла делать тест нету
прокинутый в виртуалку контроллер порвет всех

Там где это критично – данные лежат на сторадже и пробрасываются в виртуалку по FC.

Я не сталкивался с FC, но на интуитивном уровне более чем согласен. А как технически FC будет в виртуалку пробрасываться? По FC видно блочное ус-во просто и всё?

Рейд собран на S3108L-H8iR

Конфиг (юиды и сеть убрал, дабы не мусорить)

balloon: 0 boot: order=scsi0;net0 cores: 10 machine: pc-i440fx-6.0 memory: 262144 numa: 1 onboot: 1 ostype: win10 scsi0: local-lvm:vm-100-disk-0,cache=none,size=160G,ssd=1 scsi1: /dev/sdb,backup=0,replicate=0,size=7316584M,ssd=1 scsi2: /dev/nvme0n1,backup=0,replicate=0,size=3750738264K,ssd=1 scsihw: virtio-scsi-single sockets: 1 vga: virtio

Это был сарказм без злого умысла. Есть другая сторона вопроса. Что это у меня заберет…, ответ там же выше. ;)

В базе слишком много мусорных запросов из-за кривых процедур в ПО, которое собственно и вытворят сей хаос. Но это уже вопрос совсем к другим людям. Так как решения на скорую руку нет, приходится искать то, что ищу.

100k iops реально мало?

наиболее близкие к нативным иопсы ты получишь пробросив целиком контроллер.

у него не шаред-сторадж

Буду признателен, если дадите стоящий совет

Главное не стать геем, я щитаю.

Этот вариант рабочий, я полностью согласен, но не рассматривается.

Дельный совет!:)

Все же лучше уже такую капризную БД на голом железе держать

ты сделал все что мог... =)

Я до конца верил, что есть волшебная кнопка, но увы. :)

/dev/sdc — это аппаратный рейд?

Что в /sys/block/sdc/queue/scheduler

/dev/sdc,backup=0,cache=none,size=7316584,ssd=1

discard=on — пробовали?

iothread=1 — пробовали?

NUMA — включена?

cpu: host — пробовали?

Сколько ресурсов хоста проброшено в VM (ОЗУ/CPU)?

Если iops’a меряете через fio — покажите конфиг или строку запуска

Если сделать диск в памяти (tmpfs) и пробросить его в гость — то сколько там IOPs будет в госте?

Если сделать writeback — то сколько IOPs будет в госте?

PS: извините за оффтопик, но что у Вас за база такая? Обычно (в OLTP) гонятся не за IOPs’ами, а за временем записи transaction log’a. Например, вот есть статья на эту тему. То есть, Вы уверены, что СУБД у Вас генерирует 100k+ IOPs’ов (хотя бы 50k+)? Если нет, то Вы не за тем гонитесь.

критично чтение!

Тогда я бы смотрел в сторону кэша БД в первую очередь + на работу с памятью. Посмотрите, активно ли KSM (общая настройка для хоста), ballooning.

Если хост используется преимущественно для СУБД, то возможно, будет допустимо отключить фиксы аппаратных уязвимостей процессора (meltdown + spectre).

Я до конца верил, что есть волшебная кнопка, но увы. :)

Волшебная кнопка (с т.з. бизнеса) — купить подходящий PCI-E SSD и пробросить его в гостя.

Его /dev/sdc это 10-й рейд из 8 SSD, если я правильно понял.
Ему не поможет одиночный pci-e ssd.

Волшебная кнопка (с т.з. бизнеса) — купить подходящий PCI-E SSD и пробросить его в гостя.

«с т.з. бизнеса» - оторвать руки погромистам сотворившим такое и пришить на более подходящее для них место т.е. к «седалищному нерву».

По порядку изложу. /dev/sdc - да рейд аппаратный. [none] mq-deadline NUMA включена discard=on пробовал iothread=1 пробовал cpu: host - не помогло По ресурсам: 10 ядер, 256гб озу Не через fio. Замеры делаю с гостевой системы через crystaldiskmark c tmpfs не проводил тесты…, на днях займусь writeback - только ухудшает. На хосте есть еще 256гб озу, и еще 10 ядер. Которые естественно я хочу задействовать, но уже не под БД.

Самописное ПО, база 700гб, mssql, в основном чтение.