через прикладной софт. например для qemu изменить тип кэширования на writeback, тогда он не будет делать fsync, а будет писать всё асинхронным образом. Или для PG сделать fsync=off но такие изменения - чреваты. Приложения не просто так делают синхронную запись

а с writeback сильные фризы ui появляются

получается, что копирование большого файла в вм останавливает io гипервизора

а с отключенным buffer flushing?

как хранить виндовые бд ?

MSSQL?

не, я имею ввиду как пользоваться большими виндовыми бд не сохраняя их в вм )

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

не, я имею ввиду как пользоваться большими виндовыми бд не сохраняя их в вм )

ахах. да разрабы меня сьедят.

Всё лучше под бареметал. Только хрен на девелоперов напасёшься на каждый инстанс

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

ахах. да разрабы меня сьедят.

имеете ввиду mount point в контейнере ?

кстати я всё хотел проверить как будет вести себя MSSQL если ей подключить диск для баз по iscsi. Не хотите поэкспериментировать?

кстати я всё хотел проверить как будет вести себя MSSQL если ей подключить диск для баз по iscsi. Не хотите поэкспериментировать?

Давайте в курилку, ребят :)

Всё лучше под бареметал. Только хрен на девелоперов напасёшься на каждый инстанс

а зачем снижать такую нагрузку?

для stateless как-то можно ещё закрыть глаза на виртуализацию, но вот с СУБД и прочими stateful на виртуалках/облаках всё не очень хорошо, imho.

для stateless как-то можно ещё закрыть глаза на виртуализацию, но вот с СУБД и прочими stateful на виртуалках/облаках всё не очень хорошо, imho.

а с отключенным buffer flushing?

sync=standard,cache=writeback, в винде поставлен флаг turn off write-cache buffer flushing. при копировании большого файла печальное зрелище: контекстные меню открываются с задержкой в 10 сек, пуск открылся только спустя 5 секунд после окончания копирования, хотя был нажат секунд за 30 до этого. наблюдаются фризы при перемещении окон.

Special помогает. У вас же там под 700мб в сек, а без него, диски грузились дополнительной нагрузкой из-за записи метаданных и скорость была бы меньше, а под многопоточной нагрузкой разница ещё сильнее. Вопрос ведь не в общей производительности а в неравномерности доступной полосы.

В этом случае, если вы будете делать снимки, виртуальную машину нужно приостановить до моздания снимков всех zvol и разморозить после, для консистентности между сминками vdev

вот какбы уравновесить доступ к диску не прибегая к урезанию полосы.

ну или пользоваться zfs snapshot -r для рекурсивного создания снапов, эта операция атомарна

оо, даже так можно You can do multiple snapshots per zfs run and they are atomic relative to one another. zfs snapshot data/home/redmop@snap1 data/home/jimsalterjrs@snap2 надо будет по коду проверить

Спасибо. Я этот вопрос не изучал. Но, например у меня разнве vdev одной вирт машины на разных пулах. В таком режиме заморозка, по видимому, остаётся актуальной?

Я понимаю, что психологически резать полосу не приятно. Но на 100 вирт машин у вас в любом случае пул будет нагружен сильно и даже, большие записи на диск могут мешать соседьям. Я думаю, что урезание необходимо, хотябы до 200Мбайт в сек.

У меня появилось огромное желание взять и протестировать как оно падает с sync=disabled на самом деле. Можно сделать используя вложенную виртуализацию. Уронить машину 10-20 раз подряд под сильной нагрузкой на запись и посмотреть, рушится база или нет. Уверен, что не разрушится. Скриптом создавать транзакции и фиксировать их завершение, а потом посмотреть, как они откатываются. Вопрос серьёзный если мы говорим об уменьшении нагрузки в разы.

на lvm никто друг другу не мешает, даже если в вм запустить fio на полную катушку, у соседей просто чуть медленней всё.

Не согласен. Это важнейшая причина почему у меня теперь везде zfs. На lvm даже два интенсивно пишущих потока могли положить массив, а zfs точно таких же потоков может быть 10 и все работает.

ага, значит кэш аппаратного контроллера нормализует нагрузку.

Не согласен. Это важнейшая причина почему у меня теперь везде zfs. На lvm даже два интенсивно пишущих потока могли положить массив, а zfs точно таких же потоков может быть 10 и все работает.

Да. Кэш позволяет быстро принять данные, и пульнуть их в диски, создав очередь внутри буферов диска и контроллер, а не в ос. Таким образом в разы вырастает быстродействие дисков. А если контроллер может переупорядочивать запросы, сортируя их по LBA то производительность можно ускорить безмерно... правда я не знаю делают они так на самом деле или нет 😊

Из рубрики вредных советов ещё NCQ включить.

Так с NCQ диск сам решает, куда ему шпиндель гнать. Что тут такого?

Ну вы тут и написали за ночь)) Мое мнение по этому конкретному вопросу - безопасное отключение flush внутри гостя возможно при cache=writethrough и включённом sync(standard) на zvol.

Проблема в том, что из-за того, что ssd под slog не справляется с нагрузкой тормозит весь пул. Там 8 mirror vdev. Когда вы пишите, что sync=stantart -это безопасно, это как бы подразумевает, что sync=disable - это не безопасно. Но что именно означает не безопасно? Я думаю, надо уточнить. Консистентность сохранится при потери данных из writeback-буфера zfs. Можно рассмотреть этоти отключить sync там, где он не нужен.

Проблема в том, что из-за того, что ssd под slog не справляется с нагрузкой тормозит весь пул. Там 8 mirror vdev. Когда вы пишите, что sync=stantart -это безопасно, это как бы подразумевает, что sync=disable - это не безопасно. Но что именно означает не безопасно? Я думаю, надо уточнить. Консистентность сохранится при потери данных из writeback-буфера zfs. Можно рассмотреть этоти отключить sync там, где он не нужен.

вот странно что нагрузка на hdd прибегает по очереди, а не параллельно.

у меня есть причины держать бд в вм: нужно ставить то standard, то enterprise, то dev редакцию. то версии которые не поддерживаются ОС. а серверов кагбе негусто. да и в целом получилось так что в вм бд работают быстрее из-за того что на гипер дали денег )

У меня появилось огромное желание взять и протестировать как оно падает с sync=disabled на самом деле. Можно сделать используя вложенную виртуализацию. Уронить машину 10-20 раз подряд под сильной нагрузкой на запись и посмотреть, рушится база или нет. Уверен, что не разрушится. Скриптом создавать транзакции и фиксировать их завершение, а потом посмотреть, как они откатываются. Вопрос серьёзный если мы говорим об уменьшении нагрузки в разы.

тогда я бы попробовал саму ОС + бинарники для MSSQL держать на небольшом диске, а все данные на отдельном zvol. Который можно будет и снапшотить при необходимости и раздавать в разные окружения как копию прода

kill -9 процесса kvm. Это будет стресс-тест и не только для СУБД, но и для самой ОС. Вот и будет случай проверить как поднимется винда если диск будет иметь sync=disabled

небезопасно - это когда приложение (например zip-архиватор) создаёт архив, пишет заголовок, делает на него write, ОС обращается к virtio который сообщает в ОС что запись прошла успешно. А на самом деле данные ещё не записаны на файловую систему (sync=disabled). И если в этот момент пропадает питание, то "заголовок" для zip-архива не будет записан. И весь зип-архив накроется тазиком

Хорошо. Если мы создаем архивы последовательно: 1 архив, 2-й, ... и вдруг сразу после завершения архивации второго архива хост ребутнулся. В результате: sync=standart мы видим 2 архива на диске, ФС цела sync=disabled, видим только архив №1, ФС цела. Но разница между безопасно и опасна такая, я по вашему прав?

sync=standard,cache=writeback, в винде поставлен флаг turn off write-cache buffer flushing. при копировании большого файла печальное зрелище: контекстные меню открываются с задержкой в 10 сек, пуск открылся только спустя 5 секунд после окончания копирования, хотя был нажат секунд за 30 до этого. наблюдаются фризы при перемещении окон.