Есть у системы -кеш грязных страниц

А есть ещё один кеш - уже в гипервизоре

Многовато в лог падает. sync=always? Может его в enable попробовать. Убьется SSD так, даже такая.

И ещё - в локальной системе, если локальный сторадж, и в удаленной, если удаленный

В любом месте может быть врайтбек

Это именно его поведение

Так это тестируется элементарно. Воспроизводится в никсах, Стрейс на ио и иостат на диски.

никсы - это другое. тут ведоспецифичное. если есть легкий способ сгладить такое поведение, то я бы сгладил.

В любом месте может быть врайтбек

Да вроде исключили всё уже. локлаьный zfs же.

Многовато в лог падает. sync=always? Может его в enable попробовать. Убьется SSD так, даже такая.

standard

никсы - это другое. тут ведоспецифичное. если есть легкий способ сгладить такое поведение, то я бы сгладил.

Сначала отключай все кеши и воспроизводишь. Потом включай по одному

С отключёнными кошами не воспроизведешь если - это оно

С отключёнными кошами не воспроизведешь если - это оно

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

а то что в лог так много пишется это не норма ?

А с включенный sync=disabled на zvol?

что-то может подтюнить можно ?

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

Для дебага все средства хороши

И только на момент дебага

а то что в лог так много пишется это не норма ?

Нет, не норма, по моим наблюдениям. Вообще линейная запись туда не должна попадать. Тем более у вас 8 vdev -это почти 800МБ/сек! Какая SSD долго выдержит такой поток? да и не ускорится ничего, только замедлиться.

без ссд явно хуже

а то что в лог так много пишется это не норма ?

zfs get sync на zvol виртуального диска что выдаёт?

Это был у меня на sync disable, 4GB RAM, в винде все по умолчанию, копирования с диска на себя же....

Начни с настроек по умолчанию

https://pastebin.com/TyS2ykPb

zfs get sync на zvol виртуального диска что выдаёт?

standard

https://pastebin.com/TyS2ykPb

Хм. ну может и норм, хз почему так много в лог падает. А если disable сделать?

По идее вообще ничего не должно туда попадать и быстрее будет 😊

SSD->Optain никаких просадок.

Хм. ну может и норм, хз почему так много в лог падает. А если disable сделать?

провалов нет

но так же нехорошо )

SSD->Optain никаких просадок.

как-то негусто для оптана, не ?

но так же нехорошо )

Вот видите, у вас SSD прогруалась. Если бы там была optain то она бы конечно такое выдержала, а intel S4610 хороша, но не всесильна. Смотря что на дисках. Если просто файлы, а не базы данных, то именно так и должно быть. Еще раз напишу: sync disabled не значит что вы получите разрушенную фс, она означает возможность отката при на несколько сек ,если пул был максимально загружен или нескольк мили сек, если нагрузка не большая. Это не страшно для хранилища чертежей например. А вот с базами данных все зависит от того одиночная это система или работае в паре с другой, куда может быть передано состояние, которе потом откатится и связка станет неконсистентной. Например active directry успешно восстанавливает консистентность. Те. речь идет не о повреждении базы данных ао несогласованнос состоянии двух баз данных на разных виртуальных машинах, одна из которых бала неожиданно перезагруженна вместе с гипервизором и немного откатилась.

как-то негусто для оптана, не ?

Собственно, помните я говорил, что zfs - это не бесплатно. Вот. Это оно. На практике это не важно. Если будет 10 таких виртуалок писать, оно конечно прогрузить оптан.

да я не жалуюсь в целом. мне интересно понять что есть норма.

нет смысла гнатся за пиковой производительностью там, где вам нужна производительность 10-тков или даже сотен клиентов.

если способ снизить нагрузку на лог без отключения синка ?

что-то меня напугали информацией о том, что ссд так долго не проживут )

да я не жалуюсь в целом. мне интересно понять что есть норма.

Ну тут много накладных расходов на всех уровнях. Это больше не оверхед, а разные программные задержки , т.е. сам накопитель при этом не прогружен на 100%, и даже на 50 не прогружен.

что-то меня напугали информацией о том, что ссд так долго не проживут )

Проживут, если брать специально под задачи

а optane у меня один всего в пуле, и на нем еще и базы данных крутятся.

И смартить моном

Ну тут много накладных расходов на всех уровнях. Это больше не оверхед, а разные программные задержки , т.е. сам накопитель при этом не прогружен на 100%, и даже на 50 не прогружен.

про накладные расходы мне известно.

Кстати.. я у себя посчитал пенальти от зфс, и получилось чот порядка от 4 до 10. Что считается нормой?

кстати, а прокс сам умеет алертить насчет износа ссд ? )

кстати, а прокс сам умеет алертить насчет износа ссд ? )

Вроде да, надо доку листать

И смартить моном

Если на них будет сваливатся линейный трафик от копирования файлов проводником - это не очень хорошо, вернее совсем не хорошо. Я бы предложил такой критерий: Если slog ухудшает производительность, нужно постраться его исключить там где он точно не нужен. Чтобы сохранить его ресурс мощности для баз данных, например.

Если на них будет сваливатся линейный трафик от копирования файлов проводником - это не очень хорошо, вернее совсем не хорошо. Я бы предложил такой критерий: Если slog ухудшает производительность, нужно постраться его исключить там где он точно не нужен. Чтобы сохранить его ресурс мощности для баз данных, например.

Надо брать из расчета, и все

Чтобы исключить этот элемент как источник проблем

Если на них будет сваливатся линейный трафик от копирования файлов проводником - это не очень хорошо, вернее совсем не хорошо. Я бы предложил такой критерий: Если slog ухудшает производительность, нужно постраться его исключить там где он точно не нужен. Чтобы сохранить его ресурс мощности для баз данных, например.

мне линейная запись не сильно важна. скорее важны в целом иопсы.

мне линейная запись не сильно важна. скорее важны в целом иопсы.

а iops для чего? я имею ввиду что именно будет их создавать?

а iops для чего? я имею ввиду что именно будет их создавать?

будет около сотни вм, 6-10 из них будут более-менее прожорливыми до дисков. 3-4 вм с sql будет.

всё это для dev.

Ну я бы SQL положил на отдельные диски и для них включил sync=standart, а для всех остальных sync=disable

характер нагрузки будет непостоянный

всё это для dev.

А для dev казалось бы вообще везде sync=disbled где тестовые базы данных будут.

ок, если с sync=disabled невозможны поломки гостевых фс

характер нагрузки будет непостоянный

У вас может сложится такая ситуация, что нагрузка которой не требуется slog будет его использовать и прогрузит SSD и врезультате, у вас SSD будет нагружена, а диски вообще простаивать.

придумалось такое: все c disabled, а когда упс говорит что заряд ниже нормального, то включать sync нужным вм 😃

ок, если с sync=disabled невозможны поломки гостевых фс

Поломки не более возможны чем при любых других значениях sync. В прницепе, при любых sync в редких случаях ntfs упадёт, как он может упасть при обычной неожиданной перезагрузке физического сервера, т.к. не обладает танзакционностью. Sync -это не про поломки, то про то возможен откат или нет. смысл этого параметра не эквивалентет writeback обычного блочного устройства или lvm

придумалось такое: все c disabled, а когда упс говорит что заряд ниже нормального, то включать sync нужным вм 😃

Ну если хочется идеала, то наверное можно 😊 Но ведь сервер может и просто зависнуть или быть перезагружен при нехватке памяти - такое часто происходит когда памяти в притык в proxmox

Друзья. Я спать.

спасибо

Почитал, почитал всё что написали - голова кругом пошла ☹️

отдохни

Katrina очередной бот?

безопасна ли такая настройка при cache=none и sync=standard ?

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

У меня сразу вопрос: при sync=disables - zfs всегда "врёт" системе что записала, а на самом деле скидывает в zil. При sync=always -всегда выполняет честно запись на диск. Какой механизм работы при sync=standart ? 50/50 ?

Синхронные синхронно, асинхронные асинхронно

😬

У меня сразу вопрос: при sync=disables - zfs всегда "врёт" системе что записала, а на самом деле скидывает в zil. При sync=always -всегда выполняет честно запись на диск. Какой механизм работы при sync=standart ? 50/50 ?

Алексей правильно ответил. Standard это согласно флага записи - sync или async. При disabled все операции несмотря на флаг операций sync идут фактически как async. Прт always даже async запись идёт на самом деле через zil и становится sync-записью

а какие есть способы снизить нагрузку на лог при sync=standard ?

Ах, тогда ясно ) я думал sync только к синхроной записи касается.

а какие есть способы снизить нагрузку на лог при sync=standard ?

Думаю, никаких )

а какие есть способы снизить нагрузку на лог при sync=standard ?

slog

slog

я его имел ввиду )

а какие есть способы снизить нагрузку на лог при sync=standard ?

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

я его имел ввиду )

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

а какие есть способы снизить нагрузку на лог при sync=standard ?

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

Он как бы для нагрузки и предназначен