riv
тогда zpool get all имя_пула
riv
Да надо посмотреть sync для fs
riv
Если есть fs с sync=always то большой io логичен, если эта фс или zvol нагружены
riv
zfs get sync
riv
Nikolay
ниже же
Nikolay
или я совсем того
riv
Вижу
riv
Я за рулем просто. На светофоре смотрю
Nikolay
опасный
riv
Но special много и это хорошо, а на лог я бы не сказал.
riv
Но sync проверьте
Nikolay
везде standard - default
Nikolay
Но sync проверьте
если я поставлю sync=disabled на определённые датасеты, то получается это должно увеличить нагрузку на лог и снизить немного на массив ? iodelay (wa) должен стать меньше тоже ?
riv
если я поставлю sync=disabled на определённые датасеты, то получается это должно увеличить нагрузку на лог и снизить немного на массив ? iodelay (wa) должен стать меньше тоже ?
Я вам чуть позже отвечу. Задача снизить нагрузку на массив?
Vladislav
У меня один zfs volume - vmpool/vm-803-disk-0 имеет размер много больший, чем volsize 32G.
Снимков у него нету....
https://hastebin.com/share/udiqaceney.bash
имеем vmpool
# zpool status vmpool
pool: vmpool
state: ONLINE
scan: scrub repaired 0B in 00:00:03 with 0 errors on Sun Nov 12 00:24:29 2023
config:
NAME STATE READ WRITE CKSUM
vmpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
vm-data-sda ONLINE 0 0 0
vm-data-sdb ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
vm-data-sdc ONLINE 0 0 0
vm-data-sdd ONLINE 0 0 0
cache
vmpool-cache-sdf ONLINE 0 0 0
errors: No known data errors
Диски имеют такие характеристики
Disk model: LOGICAL VOLUME
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 262144 bytes / 262144 bytes
А вот кеш представляет собой SSD:
Disk model: 3E128-TS2-550B01
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 8192 bytes
I/O size (minimum/optimal): 8192 bytes / 8192 bytes
У пула vmpool ashift равен 12-ти.
Создавался так:
zpool create -o ashift=12 vmpool mirror vm-data-sda vm-data-sdb
zpool add -o ashift=12 vmpool mirror vm-data-sdc vm-data-sdd
zpool add vmpool -o ashift=13 cache vmpool-cache-sdf
Сами volume, типа vmpool/vm-803-disk-0
создает проксмокс, я особо тут при создании ничего не могу повлиять.
Alex
Лучше не заморачиваться 😊.
Из Озона за 3-4 дня доедут
https://www.ozon.ru/product/freebsd-mastery-zfs-153445416/
https://www.ozon.ru/product/freebsd-mastery-advanced-zfs-152295857/
Абалдеть, практически вся серия есть - и ssh, и sudo! С меня стакан красного, мужик! 😎
riv
если я поставлю sync=disabled на определённые датасеты, то получается это должно увеличить нагрузку на лог и снизить немного на массив ? iodelay (wa) должен стать меньше тоже ?
Почитайте про синк. Запись на это устройство происходит когда программа требует записать данные немедленно соответствующим вызовом, то zfs неотложно сбрасывает их на log.
Другими словами log уменьшает латентность на синхронных операциях, которые характерны для баз данных, при этом не увеличивая io-нагрузку на vdev-ы пула.
Sync=disable это опасный вариант настройки. Он отключает лог, но заставляет zfs врать приложению про то что данные уже записаны на диск, хотя они ещё во writeback-буфере.
Настоятельно рекомендую прочитать про то как работает лог.
С точки зрения теории масмового обслуживантя, log - это касса для покупателей с не большим количеством товара - выделенная приоритетная очередь, в то время как другие кассы имеют большие очереди из покупателей с огромнвми тележками.
В вашем случае, лучше всего поставить sync=enable
Nikolay
#Вопрос: iostat показывает большую утилизацию дисков
https://pastebin.com/raw/nEzBA8H0
При этом я не понимаю, кол-во операций в секунду чтение/запись (r/s) и (w/s) для данного пула является большим или нет?
И на log device опять же падает порой большое число операций на запись(sdj, sdk): 1100, 1300, 1600, 2700
Запустил тест на чтение: fio --directory=/lira/fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread --bs=128K --size=256M --numjobs=32 --time_based --runtime=300
Замониторил: zpool iostat -vyl 30 https://pastebin.com/raw/0s9VShfR
Немного смущает что на зеркало-2 падает в 2 раза больше операций на чтение, хотя время обработки меньше всех.
Критична ли разница во времени ожидания (total_wait) между зеркалом-2 и 0 и 1 ?
2-е зеркало местами на 50% а то и 100% быстрее 0 и 1 - 17ms против 35ms, 10ms / 22ms, но не сказать что это супер критично (наверное).
Но при этом количество читаемых данных +- одинаковое, т.е. ошибок у дисков нет, чтоб запросы перекидывать на другие диски и они за него отрабатывали.
Смарты впорядке. Диски с 4к секторами. Датасеты 128к.
Собственно вопросы:
1) пул просто не справляется с нагрузкой (большое количество запросов) ? и тогда либо уменьшить нагрузку либо попробвоать добавить ещё одно зеркало ?
2) Либо что-то с каким-то из дисков (хотя мне так не кажется) ?
3) Возможно что какое-то ПО делает слишком много запросов или много пишет-читает (постгрес какой-нить) и ложит диски?
Постарался изложить детально, как смог.
Nikolay
@riv1329 вот выше собственно что меня беспокоит по факту )
riv
И по диагностики получается что из-за диска?
riv
тупняков нет, но нагрузка на пул беспокоит
Эх надо дальше ехать. Есть что сказать вам про нагрузку. Но сейчас не успею. Мржет быть даже имеет смысл вечерком голосом.
Nikolay
Vladislav
имеем vmpool
# zpool status vmpool
pool: vmpool
state: ONLINE
scan: scrub repaired 0B in 00:00:03 with 0 errors on Sun Nov 12 00:24:29 2023
config:
NAME STATE READ WRITE CKSUM
vmpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
vm-data-sda ONLINE 0 0 0
vm-data-sdb ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
vm-data-sdc ONLINE 0 0 0
vm-data-sdd ONLINE 0 0 0
cache
vmpool-cache-sdf ONLINE 0 0 0
errors: No known data errors
Диски имеют такие характеристики
Disk model: LOGICAL VOLUME
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 262144 bytes / 262144 bytes
А вот кеш представляет собой SSD:
Disk model: 3E128-TS2-550B01
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 8192 bytes
I/O size (minimum/optimal): 8192 bytes / 8192 bytes
У пула vmpool ashift равен 12-ти.
Создавался так:
zpool create -o ashift=12 vmpool mirror vm-data-sda vm-data-sdb
zpool add -o ashift=12 vmpool mirror vm-data-sdc vm-data-sdd
zpool add vmpool -o ashift=13 cache vmpool-cache-sdf
Сами volume, типа vmpool/vm-803-disk-0
создает проксмокс, я особо тут при создании ничего не могу повлиять.
Прокс тупо берет значения ashift пула и его вставляет в volblocksize zfs volume.
Посему вопросы:
Достаточно ли volblocksize 8k для volume виртуалок? Или ставить 16к?
Надо ли там включать dedup?
Компрессию?
Станислав
Прокс тупо берет значения ashift пула и его вставляет в volblocksize zfs volume.
Посему вопросы:
Достаточно ли volblocksize 8k для volume виртуалок? Или ставить 16к?
Надо ли там включать dedup?
Компрессию?
lz4, как мне кажется, стоит включать чуть ли не всегда
Станислав
Прокс тупо берет значения ashift пула и его вставляет в volblocksize zfs volume.
Посему вопросы:
Достаточно ли volblocksize 8k для volume виртуалок? Или ставить 16к?
Надо ли там включать dedup?
Компрессию?
dedup - если скучно жить
А что будет на этом volume?
riv
В крадце. В пуле, нашгрузка может быть большой на обычные vdev, по тому что zfs так повышает быстродействие системы - организуя очереди к дискам. Это как в макдаке, чем юлиннее очередь, тем больше быстродействие кассы. Но у дисков есть ещё факто переупорядочивания секторов на четние и запись. Если в буфер загнать много заданий на запись, диск их выполнит в разы быстрее чем по одному. На 7200RPM по одной операции - это 100 iops примерно, но с очередями уже под 400 iops.
В то же время, чтобы не тупила синхронная запись, в zfs есть log. Кстати, под log и под БД, SSD слабоваты, лучше было бы выбрать S4610 - там ещё и защита буфера при потере питания есть, а у вас насколько помню нету.
А что делать с чтением - кэшировать как раз на таких SSD как у вас примерно.
В вашем случае, можно добавить пару NVME под log - какие-нибудь не большие optane или что-то от 300 000 iops на запись. А имеющиеся переделать в кэш.
Но если покупать NVME, проще сразу купить пару intel P4610 3.5TB (а меншьше то особенно и не продаются) и сделать на них пул zfs без всяких slog, special и т.д.
Про optane, у них произвоительность около 500 000 iops, но самое главное - это такая важная для бад данных величина как латентность, она там рекордно низкая. Причем кроме самой латентности важен её разброс, у optane он минимален, вто время как у обычных NVME на фоне рекордных iosp, в некоторых очередях операции могут ждать несколь десятков ms
Станислав
Это диск виртуальной машины kvm/qemu
Это то понятно, что конкретно там будет? Какой тип ФС?
Vladislav
Это то понятно, что конкретно там будет? Какой тип ФС?
Zfs и ext4.
Несколько виртуалок с разными ОС
Vladislav
Прокс тупо берет значения ashift пула и его вставляет в volblocksize zfs volume.
Посему вопросы:
Достаточно ли volblocksize 8k для volume виртуалок? Или ставить 16к?
Надо ли там включать dedup?
Компрессию?
Не надо дедуп включать
lz4 надо, вреда не принесёт, польза иногда бывает
ashift - оба вариант рабочие, 8к вреда не нанесёт
Станислав
Zfs и ext4.
Несколько виртуалок с разными ОС
ext4 имеет размер блока 4к, который Вы не можете увеличить. Если будете располагать там какую-нибудь БД, то у ext4 тоже стоит настроить stripe (как то так называется), чтобы данные одного блока данных приложения (postgres, mysql) попадали в один блок на zvol
Vladislav
Станислав
bigalloc не тоже самое, что сектор.
Станислав
Почитайте поболее про него, это опасная штука
Vladislav
Не надо дедуп включать
lz4 надо, вреда не принесёт, польза иногда бывает
ashift - оба вариант рабочие, 8к вреда не нанесёт
Вот зачем вы меня посылаете в гугл, если там в большинстве случаев устаревшие рецепты и советы...
Vladislav
Вот зачем вы меня посылаете в гугл, если там в большинстве случаев устаревшие рецепты и советы...
А в мире что-то меняется?
Vladislav
Я что-то не припоминаю, чтобы ashift меняли в коде
Vladislav
Или к примеру, что внутренний размер сектора у SSD в целом никому не известен и может быть 131072 байт или вообще 256МБ
Vladislav
Я что-то не припоминаю, чтобы ashift меняли в коде
Сейчас речь не о ashift.
C ним я определился - 13 ибо диски с 512б все меньше и меньше, а через пару лет замена вылетающих дисков - будут с приключениями
Vladislav
Сейчас речь не о ashift.
C ним я определился - 13 ибо диски с 512б все меньше и меньше, а через пару лет замена вылетающих дисков - будут с приключениями
lz4 так же не менялся с точки зрения логики, а дедуп ещё не меняли
Vladislav
И ссылка в гугл касается как раз ashift
Vladislav
Или к примеру, что внутренний размер сектора у SSD в целом никому не известен и может быть 131072 байт или вообще 256МБ
Во фряхе ssd можно переформатировать на нужный блоксайз (меньше, чем в даташите ssd)
Vladislav
Во фряхе ssd можно переформатировать на нужный блоксайз (меньше, чем в даташите ssd)
reported - да, physical? Смешно
Станислав
В последних билдах ZFS это блок по умолчанию
Vladislav
Мне нужно про volblocksize уточнить
Что-то мне подсказывает, что если OpenZFS пришёл к выводу, что 16k это новая реалия - то стоит его использовать
https://t.me/ru_zfs/38643
riv
Не надо дедуп включать
lz4 надо, вреда не принесёт, польза иногда бывает
ashift - оба вариант рабочие, 8к вреда не нанесёт
zstd жмет значительно лучше, а нагружает процесслр не сильно
riv
Принимаю совет
Файловая 1с совершенно точно лучше работает на 16К, причем в разы, чем 8К и тем более 4К или 512.
Но надо учитывать, что вышележащую фс в вм надо форматировать тоже в 16к, и базы данных настраивать, а файловую 1с конвертировать с recordsize 16K
Vladislav
zstd жмет значительно лучше, а нагружает процесслр не сильно
Можно провести тесты, единичные экземпляры продолжают показывать старую истину
LZ4 быстрее на 5-20%, но жмёт на 2-10% хуже, чем ZSTD
Vladislav
Конкретно, что подходит под нагрузку человека, покажут только тесты в условиях нагрузки человека
riv
Прокс тупо берет значения ashift пула и его вставляет в volblocksize zfs volume.
Посему вопросы:
Достаточно ли volblocksize 8k для volume виртуалок? Или ставить 16к?
Надо ли там включать dedup?
Компрессию?
Для дедуп нужны dedup vdev. Например если в качестве dedup собоать mirror из двух optane 905P (500 000 iops, 20+ PBW) то ваш zfs сможет записывать сжимать и дедуплицировать примерно 1Гбит сжатого трафика (т.е. после сжатия 1Гбит). При этом на dedup будет траыик записи от x5 до х10 крайне неудобный доя ssd - полностью случацная перезапись мелких блоков. Упирается все именно в iops dedup vdev
Если взять два optane, то получится дедупл цировать два гигабита сжатого трафика
А если вы не алигарх и у вас только "стремные" s3700, то один mirror дасть 50-100мегабит.
Другими словами, дедупликация вам потребуется в очень специфических случаях.
В среднем у меня сжатие zstd давало коэффициент х2.5 а дедупликация ещё х3 и того х7.5 но какой ценой!
А ещё будет обидно, когда вы начнете что-то удалять, а места прибавляется в х7.5 раз медленнее :-) кроме того, удаляться будет неторопливо, создавая адскую нагрузку на dedup vdev
Лежали там в основнос бекапы windows - виртуальных машин
riv
Можно провести тесты, единичные экземпляры продолжают показывать старую истину
LZ4 быстрее на 5-20%, но жмёт на 2-10% хуже, чем ZSTD
Бинарники в винде, у меня жмет в х2.5 против х1.5
Vladislav
Бинарники в винде, у меня жмет в х2.5 против х1.5
Рад за Вас. рекомендую поделиться этим опытом чуть более детально, чтобы им могли пользоваться
riv
Рад за Вас. рекомендую поделиться этим опытом чуть более детально, чтобы им могли пользоваться
Я залью чтонибудь большое и покажу разницу скорости и сжатия, но попозже
Vladislav
Я залью чтонибудь большое и покажу разницу скорости и сжатия, но попозже
Up to you
Тут всё равно речь про сравнение, поэтому не стоит забывать создать второй датасет с другим сжатием
Vladislav
У меня холодные бэкапы на больших дисках. Dedup там очень хорошо заходит
Станислав
Потому, порядок действий такой:
1) Создаём zvol с нужным volblocksize
2) Создаём ФС, для многих из них есть параметры для тюнинга под размер блока данных, чтобы ФС их складировала не разрозненно.
Например, в ext4 stride указывает, сколько кластеров должны формировать блок данных. Так как этот тюнинг рассчитан был на корректное размещение данных для raid в stripe, то, желательно, указать stripe-width. В случае с ZFS, он всегда равен stride.
3) Я отключал журналирование данных в ext4, так как у нас эту функцию выполняет zfs. Оставлял только метаданные.
4) Монтирование в виртуальной машине. К сожалению, не записал нигде. Насколько помню: data=ordered,noatime,nobarrier
@guru_support вот я описывал как-то. После таких настроек бенчмарки показывали примерно одинаковые результаты в ВМ и в контейнерах
Vladislav
Vladislav
@guru_support вот я описывал как-то. После таких настроек бенчмарки показывали примерно одинаковые результаты в ВМ и в контейнерах
Как говорится - до первого краха системы, когда у ext4 метаданные криво зайдут и надо будет откатывать транзакции у "блочного устройства"
Vladislav
Я журнал FS не планирую отключать.
Станислав
Присоединяюсь
Вы забываете, что буфер в ОП внутри ВМ можно отключить, чтобы данные сразу отправлялись на диск и сохранностью данных занималась ZFS, а не EXT4, которая делает это хуже
Vladislav
Вы забываете, что буфер в ОП внутри ВМ можно отключить, чтобы данные сразу отправлялись на диск и сохранностью данных занималась ZFS, а не EXT4, которая делает это хуже
Мне пока сохранность нужна, а не оптимизация
Станислав
Мне пока сохранность нужна, а не оптимизация
Именно потому сохранность стоит предоставить ZFS
riv
У меня холодные бэкапы на больших дисках. Dedup там очень хорошо заходит
И без dedup vdev? А какой объём пула и сколько озу?
Vladislav
Именно потому сохранность стоит предоставить ZFS
И зачем отключать ext4 журнал если это оптимизация (спорная)?
Плюс Вы забыли упомянуть тогда ещё отключение кэширования запросов в ОП
Сколько сразу нюансов появляется