Ivan
получается, что копирование большого файла в вм останавливает io гипервизора
Fedor
Не останавливает. Там есть некий процесс, который его притормаживает.
Сергей
а с writeback сильные фризы ui появляются
а с отключенным buffer flushing?
Сергей
получается, что копирование большого файла в вм останавливает io гипервизора
ну а как иначе? Ведь гипервизору нужно держать образ ВМ в консистентном состоянии чтобы если хост "грохнется" то с ВМ ничего не должно случиться
Ivan
а с отключенным buffer flushing?
через 15 минут попробую повторить тест.
Сергей
поэтому я противник огромных образов для ВМ, в которых держат данные.
Сергей
У меня средний размер дисков ВМ для линуксов это 2-4Гб, для винды 16-32Гб.
Ivan
как хранить виндовые бд ?
Fedor
В бекапах
Fedor
Не дисковых
Ivan
не, я имею ввиду как пользоваться большими виндовыми бд не сохраняя их в вм )
Fedor
Надо научиться администрировать виндовую бд, и проводить такие операции ее средствами
Fedor
Как создание, так и тест с Разворачиванием
Ivan
MSSQL?
да, от 2008 до 2016
Fedor
Это неважно блин
Fedor
:)
Сергей
не, я имею ввиду как пользоваться большими виндовыми бд не сохраняя их в вм )
есть MSSQL под линукс. Можно в контейнере сделать и положить данные на сам хост
Fedor
Тов. админы, просто - не всегда правильно
Сергей
не, я имею ввиду как пользоваться большими виндовыми бд не сохраняя их в вм )
и делать их на бареметалл. СУБД внутри ВМ живут не самым лучшим образом
Fedor
Вооот подбираемся к истине
Fedor
ахах. да разрабы меня сьедят.
А им какая разница? У них есть порт 1443
ivdok
Всё лучше под бареметал. Только хрен на девелоперов напасёшься на каждый инстанс
ivdok
Поэтому гиперконгервентность во все щели
Fedor
Всё лучше под бареметал. Только хрен на девелоперов напасёшься на каждый инстанс
Тестовые вообще можно не бекапить. Снапшот чистой системы с преднамеренной бд - пусть сами разливают тестовый набор данных
Fedor
Давайте в курилку, ребят :)
Сергей
ахах. да разрабы меня сьедят.
кстати я всё хотел проверить как будет вести себя MSSQL если ей подключить диск для баз по iscsi. Не хотите поэкспериментировать?
Сергей
Всё лучше под бареметал. Только хрен на девелоперов напасёшься на каждый инстанс
для stateless как-то можно ещё закрыть глаза на виртуализацию, но вот с СУБД и прочими stateful на виртуалках/облаках всё не очень хорошо, imho.
riv
а зачем снижать такую нагрузку?
Проблема в том, что из-за того, что ssd под slog не справляется с нагрузкой тормозит весь пул. Там 8 mirror vdev. Когда вы пишите, что sync=stantart -это безопасно, это как бы подразумевает, что sync=disable - это не безопасно. Но что именно означает не безопасно? Я думаю, надо уточнить. Консистентность сохранится при потери данных из writeback-буфера zfs. Можно рассмотреть этоти отключить sync там, где он не нужен.
Ivan
для stateless как-то можно ещё закрыть глаза на виртуализацию, но вот с СУБД и прочими stateful на виртуалках/облаках всё не очень хорошо, imho.
у меня есть причины держать бд в вм: нужно ставить то standard, то enterprise, то dev редакцию. то версии которые не поддерживаются ОС. а серверов кагбе негусто. да и в целом получилось так что в вм бд работают быстрее из-за того что на гипер дали денег )
riv
для stateless как-то можно ещё закрыть глаза на виртуализацию, но вот с СУБД и прочими stateful на виртуалках/облаках всё не очень хорошо, imho.
У меня появилось огромное желание взять и протестировать как оно падает с sync=disabled на самом деле. Можно сделать используя вложенную виртуализацию. Уронить машину 10-20 раз подряд под сильной нагрузкой на запись и посмотреть, рушится база или нет. Уверен, что не разрушится. Скриптом создавать транзакции и фиксировать их завершение, а потом посмотреть, как они откатываются. Вопрос серьёзный если мы говорим об уменьшении нагрузки в разы.
Ivan
а с отключенным buffer flushing?
sync=standard,cache=writeback, в винде поставлен флаг turn off write-cache buffer flushing. при копировании большого файла печальное зрелище: контекстные меню открываются с задержкой в 10 сек, пуск открылся только спустя 5 секунд после окончания копирования, хотя был нажат секунд за 30 до этого. наблюдаются фризы при перемещении окон.
Ivan
почему в данном случае никак не помогает special ?
riv
Special помогает. У вас же там под 700мб в сек, а без него, диски грузились дополнительной нагрузкой из-за записи метаданных и скорость была бы меньше, а под многопоточной нагрузкой разница ещё сильнее. Вопрос ведь не в общей производительности а в неравномерности доступной полосы.
riv
Не являясь про в mssql, хочу заметить, что имеет смысл изучить то как работает его лог. Может быть, можно рассмотреть связку sync=disabled на базе данных и sync=standart на выделенном устройстве под лог mssql? Но это надо тестировать. Это просто идея.
riv
В этом случае, если вы будете делать снимки, виртуальную машину нужно приостановить до моздания снимков всех zvol и разморозить после, для консистентности между сминками vdev
riv
вот какбы уравновесить доступ к диску не прибегая к урезанию полосы.
Я понимаю, что психологически резать полосу не приятно. Но на 100 вирт машин у вас в любом случае пул будет нагружен сильно и даже, большие записи на диск могут мешать соседьям. Я думаю, что урезание необходимо, хотябы до 200Мбайт в сек.
George
оо, даже так можно 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 надо будет по коду проверить
riv
ну или пользоваться zfs snapshot -r для рекурсивного создания снапов, эта операция атомарна
Спасибо. Я этот вопрос не изучал. Но, например у меня разнве vdev одной вирт машины на разных пулах. В таком режиме заморозка, по видимому, остаётся актуальной?
Ivan
и если я полосу ограничу, это значит что не будет никакой дополнительной производительности, когда диски хоста ничем не заняты
ivdok
Вот если журнал кранты, тогда пиши пропало, но это на любой базе так
ivdok
Хочу сказать, что с ZFS коррапта меньше будет, но как я понял тут кейс с NTFS поверх zvol?
riv
на lvm никто друг другу не мешает, даже если в вм запустить fio на полную катушку, у соседей просто чуть медленней всё.
Не согласен. Это важнейшая причина почему у меня теперь везде zfs. На lvm даже два интенсивно пишущих потока могли положить массив, а zfs точно таких же потоков может быть 10 и все работает.
riv
ага, значит кэш аппаратного контроллера нормализует нагрузку.
Да. Кэш позволяет быстро принять данные, и пульнуть их в диски, создав очередь внутри буферов диска и контроллер, а не в ос. Таким образом в разы вырастает быстродействие дисков. А если контроллер может переупорядочивать запросы, сортируя их по LBA то производительность можно ускорить безмерно... правда я не знаю делают они так на самом деле или нет 😊
Fedor
Вот нагородите сейчас, потом данные будете терять
Fedor
Слог не может тормозить нагрузку никак
Fedor
Единственное ограничение - скорость записи на медленные диски. С физикой не поспоришь
ivdok
Из рубрики вредных советов ещё NCQ включить.
Так с NCQ диск сам решает, куда ему шпиндель гнать. Что тут такого?
Fedor
Так с NCQ диск сам решает, куда ему шпиндель гнать. Что тут такого?
Зфс получает информацию о записи блока, когда он ещё не записан
Fedor
Это очень плохо
Ivan
Ну вы тут и написали за ночь)) Мое мнение по этому конкретному вопросу - безопасное отключение flush внутри гостя возможно при cache=writethrough и включённом sync(standard) на zvol.
если измерять на глазок, то с cache=writetrough с настройками винды по дефолту лучше отзывчивость, чем с отключенным flush. если сравнивать с дефолтными настройками винды то, c cache=none чуть шустрее работает ui, но нагрузка на ssd на порядок выше. c cache=writetrough меньше нагрузка на ssd, writeback мне совсем не понравился.
Ivan
возможно тут прокс сильно вмешивается.
Сергей
Проблема в том, что из-за того, что ssd под slog не справляется с нагрузкой тормозит весь пул. Там 8 mirror vdev. Когда вы пишите, что sync=stantart -это безопасно, это как бы подразумевает, что sync=disable - это не безопасно. Но что именно означает не безопасно? Я думаю, надо уточнить. Консистентность сохранится при потери данных из writeback-буфера zfs. Можно рассмотреть этоти отключить sync там, где он не нужен.
небезопасно - это когда приложение (например zip-архиватор) создаёт архив, пишет заголовок, делает на него write, ОС обращается к virtio который сообщает в ОС что запись прошла успешно. А на самом деле данные ещё не записаны на файловую систему (sync=disabled). И если в этот момент пропадает питание, то "заголовок" для zip-архива не будет записан. И весь зип-архив накроется тазиком
Ivan
вот странно что нагрузка на hdd прибегает по очереди, а не параллельно.
riv
вот странно что нагрузка на hdd прибегает по очереди, а не параллельно.
Вероятно это из-за того, что logbias=latency но лучше так оставить для будущей многопоточной нагрузки.
Сергей
у меня есть причины держать бд в вм: нужно ставить то standard, то enterprise, то dev редакцию. то версии которые не поддерживаются ОС. а серверов кагбе негусто. да и в целом получилось так что в вм бд работают быстрее из-за того что на гипер дали денег )
тогда я бы попробовал саму ОС + бинарники для MSSQL держать на небольшом диске, а все данные на отдельном zvol. Который можно будет и снапшотить при необходимости и раздавать в разные окружения как копию прода
riv
небезопасно - это когда приложение (например zip-архиватор) создаёт архив, пишет заголовок, делает на него write, ОС обращается к virtio который сообщает в ОС что запись прошла успешно. А на самом деле данные ещё не записаны на файловую систему (sync=disabled). И если в этот момент пропадает питание, то "заголовок" для zip-архива не будет записан. И весь зип-архив накроется тазиком
Хорошо. Если мы создаем архивы последовательно: 1 архив, 2-й, ... и вдруг сразу после завершения архивации второго архива хост ребутнулся. В результате: sync=standart мы видим 2 архива на диске, ФС цела sync=disabled, видим только архив №1, ФС цела. Но разница между безопасно и опасна такая, я по вашему прав?