« Rev
@ru_zfs   397
Fwd »


Art
ну, не хороши или плохи, а подходят под нагрузку или не подходят.
с этим соглашусь на 100%, но просто ВМ и БД предполагают высокую долю записи, следовательно raidZ не очень им подходят
Nick
а проверяли?
Nick
# zpool iostat 1 capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- tank 364G 1.44T 24 41 351K 1.49M capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- tank1 149G 295G 7 66 169K 1.76M tank2 297G 147G 4 28 104K 675K capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- tank 502G 222G 69 372 751K 21.7M Первые три попавшиеся под руку сервера из списка наиболее нагруженных. Виртуалки, битрикс, всё такое.
Art
Пока речь идет о виндовых терминалах, никаких БД там не будет. Запуск офисных приложений, браузеров и тп.
проверь свой ашифт: zpool get ashift RAIDz10 Если он 9, то норм, и ничего пересоздавать не надо. Что касается твоих ZVOL , то если ты их создавал из GUI прокса, то скорее всего они 8К. Проверь это так: zfs get volblocksize RAIDz10/vm-100-disk-0 Ashift 9 и volblocksize 8к - думаю, производительность будет ОК, а сжатие даже ещё сильнее, чем когда ашифт=12 и volblocksize=8K (у меня так)
Nick
про директио которое тут недавно обсуждалось - на сколько я вижу - оно не смержено и там сплошное WIP - https://github.com/openzfs/zfs/pull/10018
Nick
хотя есть https://github.com/openzfs/zfs/commit/a584ef26053065f486d46a7335bea222cb03eeea
Nick
и в 2.1 оно видимо смержено
Nick
и видимо начиная с 0.8
George
и видимо начиная с 0.8
ага, с 0.8 zfs теперь не шлёт лесом, а фиктивно "умеет" но по факту пока игнорит, данные всё равно через arc идут как обычно
nikolay
Не совсем понял зачем делать чтение мимо arc
George
Не совсем понял зачем делать чтение мимо arc
ну тот патч начался с того, что для массива из большого количества nvme ARC уже является узким местом
Александр
или 75 был родной не помню
nikolay
На серверных?
Не знаю, Георгий пишет что с этого кейс начался
Иван
Не пул большой, а количество дисков. Говорят 6 уже большой.
Δαρθ
это то есть нвме стали быстрее чем ОЗУ? или просто арк имеет такие медленные алгоритмы? :)
Δαρθ
ну линки pci-e точно так же от нумы страдают
Nick
Хм, кто то пробовал собирать большие пулы на nvme, интересно..
там даже на одном нвме эта проблема хорошо заметна (
Nick
это то есть нвме стали быстрее чем ОЗУ? или просто арк имеет такие медленные алгоритмы? :)
арк - это довольно много логики. По факту - даже на 5 гигагерцевых ядрах он узкое место если дальше нвме
George
арк - это довольно много логики. По факту - даже на 5 гигагерцевых ядрах он узкое место если дальше нвме
да и не только в zfs это стреляет, в общем то. Очень грубо ddr4 даёт в dual channel около 50ГБайт\сек на доступ, какой-нибудь memcopy это уже около 13-15ГБайт\сек. И каждая манипуляция с данными стоит чего-то. Так что 4+ nvme промышленных и попытки собрать массив из них быстро на это нарываются. Началось всё тут про nvme и directio, если кому интересно https://github.com/openzfs/zfs/issues/8381
George
(речь про поточку, а не рандом)
George
там стараются смотреть на то что протухает и вешать если надо
George
ну и если увидел интересное - пиши в тикете, обновим актуальной, в этом смысл в частности)
Nick
https://github.com/openzfs/zfs/issues/6531 - вот это закрыто зря, проблема существует
Nick
btw, есть ли способ как-то оптимальнее агрегировать запись, кроме накладывания вручную патчика https://github.com/openzfs/zfs/issues/8472#issuecomment-960310603 ?
Nick
увеличивать /sys/module/zfs/parameters/zfs_txg_timeout уже пробовал
George
https://github.com/openzfs/zfs/issues/6531 - вот это закрыто зря, проблема существует
Емнип сам Грегг писал что больше не стреляло у себя)
Nick
надо проверить, но кажется я продолжаю наблюдать это на 2.1
George
надо проверить, но кажется я продолжаю наблюдать это на 2.1
если воспроизводится - пиши в тикете, ага
Nick
ситуация конечно уже улучшилась, причем всё стало резко лучше при переходе на 5.11 ядро. с 5.4 вообще было много странного с зфс
George
увеличивать /sys/module/zfs/parameters/zfs_txg_timeout уже пробовал
write throttling крутить можно, но надо прям разобраться как он работает чтобы правильно настроить https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Async%20Write.html
Nick
а как коррелирует количество потоков записи с, видимо, write amplification в этом случае?
George
а как коррелирует количество потоков записи с, видимо, write amplification в этом случае?
через их количество тротлят (ограничивают запись) когда набили буфер dirty data до определённого порога
Nick
в данном случае у меня ссд, я не упираюсь в ио, но имею большую запись в мегабайтах в сценарии, в котором вроде бы столько быть не должно. И там мускль. Я подозреваю много cow операций, которые приводят к большому write amplification
George
т.е. сейчас при явном тротлинге можно увидеть, как некоторые потоки на запись ожидают
George
recordsize какой под мускулем?
Nick
16к
George
тогда не должно быть, это == размеру блока у innodb
Nick
казалось бы, но вот .
George
надо искать дальше
George
Кстати, 8-9 ноября будет проходить OpenZFS Dev Summit, ещё есть 2 дня зарегистрироваться https://www.eventbrite.com/e/openzfs-developer-summit-2021-tickets-166105683571
George
Вот список выступлений https://openzfs.org/wiki/OpenZFS_Developer_Summit_2021
Alexandr
👍
Nick
поверхностно ещё тут для мускуля рекомендации есть https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#innodb
кстати да, skip-innodb_doublewrite похоже заметно улучшило ситуацию (но явно лишь частично)
Nick
А как сейчас менять шедулер? zfs_vdev_scheduler больше не поддерживается (что, кстати, не отражено в документации), про правила udev что-то нагугливается, но как оно работает вообще, у zfs всё-таки свой сейчас шедулер, или ядерный линуксовый используется? Если на одном диске ext4 и zfs на разных разделах, то можно сделать только одинаковый?
Δαρθ
а как зфс может иметь свой шедулер мимо линуксового? все равно ж запросы в диск идут стандартным путём?
Nick
https://github.com/openzfs/zfs/issues/9778
Nick
и это было в релиз ноутсах
Nick
к какой-то в эпоху 0.8
Nick
я давно про это читал, потом забыл, сейчас пошел смотреть и поудивлялся варнингам в дмесг
Combot
Tommy Simon has been banned! Reason: CAS ban.
Василий
А вот что зфс-ное можно поставить на флешку? Есть сервер, на 4 диска, хочется этим диски отдать как хранилку и на них ничего не ставить. А саму систему на флешку кинуть
Василий
Собственно мне все равно что там будет, но нужен хотябы псевдо мультитаер на чтение
Василий
пошел читать
Сергей
пошел читать
или https://www.esos-project.com
Василий
или https://www.esos-project.com
О. Очень интеересно.вроде то что надо. Спасибо
Сергей
О. Очень интеересно.вроде то что надо. Спасибо
да). и там zfs on linux (значит должен быть актуальным) + iscsi target хороший
Василий
Меня только смутило, что они фразу: продуктивной среднее, слово "production" в кавычки заключили)
Сергей
я бы не сказал что проект сильно массовый. Но он уже давно существует и судя по активности на гитхабе - развиваетя. Просто очень нишевой. Может кто-то даже и "свои" хранилки на нём делает
Сергей
Меня только смутило, что они фразу: продуктивной среднее, слово "production" в кавычки заключили)
там ведь всё в базе из ядра линукса. они мержат с основной веткой время от времени. А гуи (консольная) - вряд ли будет как-то влиять на надёжность я в своё время именно под отдельную хранилку её рассматривал. Но так руки и не дошли под нагрузкой протестировать scst
Сергей
Под scst по прежнему надо ядро патчить?
у esos он уже добавлен в их ядро.
nikolay
Аа, это хорошо
« Rev
@ru_zfs   397
Fwd »