проц, память, контроллер, провода, БП, диски что-то из этого сбоит, нужно искать

то-есть ресильвер он только при замене диска на пустой. А если синхронизация сбойного диска то скраб все поправит, а клеар просто снимет метки о сбое и напишет что все ок?

то-есть ресильвер он только при замене диска на пустой. А если синхронизация сбойного диска то скраб все поправит, а клеар просто снимет метки о сбое и напишет что все ок?

сбоило на старой, продолжает на новой

ага

и дальше то чего, вот дождусь я выполнения команды, он деградировал, мне просто чистить ошибки?? ИЛи что-то надо делать

один разок был другой, но я полагаю могло быть из-за грубого выключения питания

Я думаю, это норма, если диски механические. У вас полторы тысячи iops на 6 дисках на чтение и столько же на запись. Каждый дисков даёт в честном синхронном режиме, максимум 100iops, ну 200, если 10к RPM, ну хорошо, 300, если это 15к. Добавление небольшого special vdev и SLOG vdev на SSD повысит скорость в разы, а может быть и на порядок. Но тестирование в синхронном режиме, на мой взгляд, бесполезная затея. zfs создан таким образом, чтобы как раз этого синхронного избежать. Именно для этого zfs использует транзакционную запись и сохраняет косистентность без использования синхронной записи. Т.е. это самый не удобный, и часто бесполезный case.

Что-то не очень. Особенно в синхронном режиме 🙄🤔 Или без служебных vdev это норма ?

Под какие цели будет использоваться пул? Как правильно отметили - добавление SLOG поможет увеличить синхронную запись, но возможно это вам и не требуется.

под vps. Есть вм с mssql и контейнеры с postgres, mysql

SSD в пути. Будет slog и special. На одном зеркале правда. Ничего же криминального нет в этом ?

Без slog будет тяжко. А почему не сделали пул на ссд? Я конечно понимаю что ответ будет про финансы. Но в 2020 собирать из хдд хранилище под базы и виртуалки уже как-то неприлично)

Да, дело в финансах )) Хотя я не считал сколько денег на ssd уйдёт. Хранился на 18 Тб (полезной ёмкости) диски по 6т hdd.

А сколько ОЗУ будет на хосте?

под арк я выделил минимум 4 Гб а максимум 26 Гб

Маловато для пула из дисков по 18Тб. Возможно вам лучше будет l2arc из ссд добавить ещё в пул

1Гб на 1Тб руководствовался этим )

Ну блин, нормальные цифры же для синхронной записи на hdd. Однопоток не сможет все vdevs заюзать же всё равно. Хочется нормальных цифр - slog нужен, он для этого и придуман

это само собой. Просто ожидал что будет быстрее 🙂

почему?)

Просто казалось что SAS диск 7200rpm может писать больше чем 4,5 Мб в секунду :) у меня нет опыта в этой сфере, бенчи никогда не делал до этого.

Просто казалось что SAS диск 7200rpm может писать больше чем 4,5 Мб в секунду :) у меня нет опыта в этой сфере, бенчи никогда не делал до этого.

Qd ?)

С 1 как то не прилично))

так наоборот самый честный тест на синхронную запись

Iodepth

так там 4 и 16 IOD

Я не думаю что в боевой нагрузке это будет именно так

Уверены?

Хм. Посомтрю. Там через скрипт должно было подставляться.

ну это уже другой вопрос - соответствие бенчей и боевой нагрузке. Лучше на бенчах понять ситуацию, чем потом на боевой нагрузке воткнуться Хочется ближе к реальному - pgbench можно тот же потестить тогда проще

А смысл🤷‍♂️кто то использует базу с 1 клиентом))

ну это уже другой вопрос - соответствие бенчей и боевой нагрузке. Лучше на бенчах понять ситуацию, чем потом на боевой нагрузке воткнуться Хочется ближе к реальному - pgbench можно тот же потестить тогда проще

Существуют утилиты захвата и воспроизведения боевой нагрузки, кстати. Можно запусать активность за день и воспроизвести.

Для 18Тб, если там хотя бы 10% займут реально работающие базы данных, может не хватить производительности. Special обязательно, но можно и в чтение упереться. В крайнем случае, всегда можно включить sync=disabled. Я вообще не особенно понимаю смысл sync=enable когда используются sas диски с резервированеым линком, сервер с двумя БП каждый из которых на своем резерве + байпасс. Это что должно произойти, чтобы что-то разрушилось? С другой стороны, в режиме sync=disabled данеые всегда в консистентном состоянии. Если у вас нет систем, которые не переживут откат на несколько секунд назад, это неплохой выход.

Хм. Посомтрю. Там через скрипт должно было подставляться.

так я повторюсь же - вопрос методики бенча. Хотите проверить 100 юзеров - надо не iodepth менять а numjobs

кстати раз уже многие полагаются на тот скрипт, то наверное нужно в него добавить и разные numjobs. Но он и так уже выполняется под полчаса, а так ещё будет мультиплицирован на число вариантов

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

а есть какой-то скрипт?) на zfs на большом количестве numjobs как раз хорошо должно быть, он умеет агрегировать отлично

при запуске bench.sh можно указать идентификатор, который будет добавлен в имя файла

Всем привет