nikolay
если бы еще в тесте было пару nvme под slog.. но чего нет, того нет..
Alexander
Действительно, вы правы Владимиру на его Кингстоне следует тестить только поток ..имхо.. на рандоме ,больше чем у него было ,думаю не добится
Alexander
"мелкоблочным"
nikolay
Действительно, вы правы Владимиру на его Кингстоне следует тестить только поток ..имхо.. на рандоме ,больше чем у него было ,думаю не добится
зависит от того насколько он будет забивать ssd по объему имхо. если больше 50-60% и гонять тесты минимум пару часов чтобы пробить slc кэш - то да, 4-8к iops на запись для этого ssd уже хороший показатель под нагрузкой. на чтение за счет увеличения кол-ва потоков может можно будет больше получить, но какая будет при этом latency - вопрос..
nikolay
несмотря на то, что диски собраны в пул по аналогии с raid10, хотя на самом деле застрайпленные мирроры под zfs не являются полным аналогом raid10 в его классическом понимании.
Сергей
"мелкоблочным"
на размере блока 1М на randrw этот raid10 выдаёт 3.5Gb/s, на запись 1.5Gb/s
Сергей
это же под PBS, там нет смысла иметь маленький recsize.
Сергей
Alexander
да
блок в fio 1M?
Сергей
Alexander
да
ну я и говорил, что с мелкоблочкой смысла нет, а вот с большим блоком вопрос был открыт)) спасибо!
Сергей
неплохо. а не сравнивали с raidz2?
нет, это уже Владимир сам сделает видимо. Рекомендации я выдал)
nikolay
70/30
ага, тогда точно неплохо
Сергей
хотя в его условиях (как сервер для бэкапов) - можно и наоборот делать. Или хотя бы 50/50
nikolay
нет, это уже Владимир сам сделает видимо. Рекомендации я выдал)
ок, может Владимир поделится с нами результатами для raidz2..
Владимир
pool: tank state: ONLINE config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 scsi-350026b7683410715 ONLINE 0 0 0 scsi-350026b7683410975 ONLINE 0 0 0 scsi-350026b768341050a ONLINE 0 0 0 scsi-350026b76834105d1 ONLINE 0 0 0 scsi-350026b76834104e7 ONLINE 0 0 0 scsi-350026b7683410525 ONLINE 0 0 0 scsi-350026b7683410535 ONLINE 0 0 0 scsi-350026b7683410994 ONLINE 0 0 0 errors: No known data errors
Владимир
Run status group 2 (all jobs): READ: bw=2030MiB/s (2129MB/s), 2030MiB/s-2030MiB/s (2129MB/s-2129MB/s), io=179GiB (192GB), run=90387-90387msec WRITE: bw=870MiB/s (912MB/s), 870MiB/s-870MiB/s (912MB/s-912MB/s), io=76.8GiB (82.5GB), run=90387-90387msec
Владимир
Владимир
Сергей
по записи
Сергей
хотя.. смотрю полный отчёт - всё не так плохо)
Сергей
первая группа - это async randrw, вторая sync=1, треться fsync=1.
Владимир
Да Сергей, после Вашего тюнинга производительность выросла в разы! Спасибо огромное!
Владимир
RECSIZE=1М
Alexander
файл какого размера?))
Alexander
теперь чет я засомневался в этом тесте на rz2))
Alexander
диск жешь по мануалу такой макс. бендвич не дает))
Владимир
как есть
Alexander
как есть
Ну такого быть просто не может🤷‍♂️
Сергей
диск жешь по мануалу такой макс. бендвич не дает))
один диск не даёт, но там же массив собран. Запись параллельно идёт
Сергей
там 8 дисков, каждый по спекам якобы может выдать до 500Мб/с
Сергей
Да Сергей, после Вашего тюнинга производительность выросла в разы! Спасибо огромное!
попробуйте в bench.fio изменить размер файла на 250-300Гб, чтобы полностью исключить влияние кэша ОЗУ
Alexander
в мирор -да
Владимир
пересобрал raidz1 и запустил тест. Как закончится повторю с 250-300Гб
Владимир
👌
nikolay
не не. в rz емнип пр-сть одного девайса
+, был же собран пул на одном vdev в raidz2
Сергей
не не. в rz емнип пр-сть одного девайса
возможно в таком случае есть эффект от кэша, хотя там джоб много и даже sync/fsync включены. Посмотрим на другом размере файла
Alexander
там 32,
а ОЗУ сколько?
Alexander
64
ну 100 пусть сделает файлик
nikolay
+, был же собран пул на одном vdev в raidz2
можно же кстати сделать пул из 2-х vdev в raidz2 или raidz1 и сравнить.
Alexander
можно же кстати сделать пул из 2-х vdev в raidz2 или raidz1 и сравнить.
для начала, хотелось бы с 1 vdev адекватные цифры получить)
Alexander
хотя они примерно понятны))
Alexander
что не могут быть больше пр-сти сырого девайса
nikolay
что не могут быть больше пр-сти сырого девайса
кстати говоря читал что это не совсем верно в случае последовательной нагрузки. попробую найти в закладках..
Владимир
Владимир
компрессия выключена?
это довольно сомнительное преимущество))
Владимир
если вообще преимущество
Сергей
это довольно сомнительное преимущество))
речь о другом. Там её нужно выключить
Alexander
это довольно сомнительное преимущество))
Это не преимущество)) мы исключаем ее воздействие
Владимир
аа
Владимир
ну так она обычно имеет положительное воздействие
Владимир
если речь про lz4
Alexander
Сергей
не не. в rz емнип пр-сть одного девайса
вот смотрю статью - там производительность одного устройства ниже чем raidz https://calomel.org/zfs_raid_speed_capacity.html
Владимир
перезапустил тест на raidz1 с файлом 100. Скоро будут результаты
Владимир
Run status group 0 (all jobs): READ: bw=4567MiB/s (4788MB/s), 4567MiB/s-4567MiB/s (4788MB/s-4788MB/s), io=179GiB (192GB), run=40159-40159msec WRITE: bw=1961MiB/s (2056MB/s), 1961MiB/s-1961MiB/s (2056MB/s-2056MB/s), io=76.9GiB (82.6GB), run=40159-40159msec Run status group 1 (all jobs): READ: bw=2878MiB/s (3018MB/s), 2878MiB/s-2878MiB/s (3018MB/s-3018MB/s), io=179GiB (192GB), run=63765-63765msec WRITE: bw=1233MiB/s (1293MB/s), 1233MiB/s-1233MiB/s (1293MB/s-1293MB/s), io=76.8GiB (82.4GB), run=63765-63765msec Run status group 2 (all jobs): READ: bw=2155MiB/s (2259MB/s), 2155MiB/s-2155MiB/s (2259MB/s-2259MB/s), io=179GiB (192GB), run=85166-85166msec WRITE: bw=924MiB/s (968MB/s), 924MiB/s-924MiB/s (968MB/s-968MB/s), io=76.8GiB (82.5GB), run=85166-85166msec
Alexander
оочень странно))) ну дай бог дай бог)))
Владимир
Сергей
оочень странно))) ну дай бог дай бог)))
обратная сторона - там конечно латенси дикое и IOPS не очень много конечно, но для бэкап-сервера это думаю вообще не важно. Там сустейнед скорость будет более важна для записи