𝚔𝚟𝚊𝚙𝚜
Из pro_kvm
Fedor
👍
Fedor
Всем привет!
Ivan
кого заманили 😃
Сергей
А aes-ni оно поддерживает?
https://github.com/openzfs/zfs/issues/9572
Олег
Да
Евгений
https://github.com/openzfs/zfs/issues/9572
Самое быстрое закрытие бага :)) Интересно, а сколько должна быть запись на пул, что бы уложить проц
Олег
так латенси улучшится, если есть поддердка aes
для шифрования только так понимаю
Сергей
для шифрования только так понимаю
да. данным патчем. Но ещё пара патчей должна добавить скорость при работе с zvol. найду свободный хост - проверю fio....
Евгений
так латенси улучшится, если есть поддердка aes
Ну я на бсд юзаю зфс, старый горшок когда то гонял, там 35 мегабайт был потолок с 2 ядрами по 2 ГГц без aes-ni. 5120 по-моему. А вот е5-2120 сильно не напрягается на 600МБсек
Fedor
Чтобы в квм не флудить, спрошу тут. Кто под какие задачи какие размеры рекордов использует?
Fedor
👍
Fedor
А звол/qcow ос win/nix?
Сергей
А звол/qcow ос win/nix?
дефолтные 8к. но у меня nvme, возможно для hdd стоило бы поиграть размерами для совпадения с размером внутри самой ОС
George
дефолтные 8к. но у меня nvme, возможно для hdd стоило бы поиграть размерами для совпадения с размером внутри самой ОС
для hdd, кстати, иногда имеет смысл наоборот размер блока увеличивать, у них дорогой seek time, но практически не отличающийся для маленьких блоков read time непосредственный.
Fedor
Вот хдд как раз
nikolay
Сергей
Интересно, а почему для wal 128?
жмётся лучше и реже запись.
nikolay
Эм.. а зачем логи сжимать? Их может быть так много? Реже запись из за компрессии?
George
Эм.. а зачем логи сжимать? Их может быть так много? Реже запись из за компрессии?
Чем лучше сжимается - тем меньше размер на диске = меньше IO требуется
nikolay
Для data я кстати обычно 128 оставляю, все равно блоки разного размера прилетают
George
в общем то почему на hdd lz4 сжатие практически маст хев уже, на его latency очень хорошо занимается cpu сжатием
Сергей
Эм.. а зачем логи сжимать? Их может быть так много? Реже запись из за компрессии?
lz4 практически не забирает CPU. в принципе для датасета с WAL можно и отключить компрессию, там всё равно объём небольшой хранится.
George
Для data я кстати обычно 128 оставляю, все равно блоки разного размера прилетают
ага, вообще для случаев, когда файл вычитывают всегда весь (например, статика), можно и 1МБ ставить, если компрессия включена то последний блок даже если будет пустым - сожмётся
nikolay
Чем лучше сжимается - тем меньше размер на диске = меньше IO требуется
Это понятно, просто логов обычно немного и есть рекомендации по рекорд сайз в 8 кб
Сергей
Для data я кстати обычно 128 оставляю, все равно блоки разного размера прилетают
а вот с датой я экспериментировал, пробовал от 8к до 128к делать. на 8к получал по pg_bench лучше всего результаты, но слабую компрессию. Оставил 16 как некий компромис
nikolay
а вот с датой я экспериментировал, пробовал от 8к до 128к делать. на 8к получал по pg_bench лучше всего результаты, но слабую компрессию. Оставил 16 как некий компромис
Pg_bench плюс минус остановка в моем случае показывал на 8-16к рекорд сайзе как и при 128к. А вот компрессия ощутимо лучше при 128к
Сергей
сколько людей, столько мнений)) PostgreSQL 11.4.1, 8GB RAM, 30GB DB: TPC-B: recsize=8k, tps = ~13400 recsize=16k, tps = ~15400 recsize=128k, tps = ~8400 pgbench -U postgres -j 32 -c 32 -M prepared -T 120 -v -P 5 pgbench
Fedor
интересный инструмент.
nikolay
Хм.. tps это одна едентца измерения, я больше все же на iops ориентируюсь
nikolay
Единица*
nikolay
Не, я смотрю статистику по пулу
Сергей
интересный инструмент.
что было из штатных, тем и пришлось мерять.
Сергей
Не, я смотрю статистику по пулу
т.е. запускаете pgbench, но на результаты pgbench не смотрите, а наблюдаете через iostat показатели пула?
nikolay
Да
nikolay
Как эти самые tps на уровне пула в виде io ложатся на диски
Сергей
странно что percona и 2ndquadrant меряют через tps в своих статьях.
Сергей
https://www.2ndquadrant.com/en/blog/pg-phriday-postgres-zfs/
Сергей
https://habr.com/ru/post/458156/
nikolay
вторую читал вроде в оригинале..
nikolay
а по первой ссылке в разделе "They both met movie stars, partied and mingled" говорят ровно про то о чем я выше написал
nikolay
Astute readers may have noticed we didn’t change the default ZFS block size from 128k to align with the Postgres default of 8kb.
nikolay
и листинг zfs get compressratio для recordsize = 8к и 128к
Сергей
да я и не спорю что с 128 компрессия будет лучше. Для себя в качестве компромисса между сжатием и tps я выбрал 16. Сжатие вышло ~x3, мне достаточно.
nikolay
я тоже не спорю что по tps результаты могут быть лучше при recordsize отличном от 128к. но вот на уровне пула по iops они очень близкими друг относительно друга получались в моем случае. может как раз компрессия позволяет сглаживать разницу..
Олег
https://habr.com/ru/post/458156/
сам делал тесты, zfs под бд не сильно жизнеспособен на нагрузках, упор в нашем случае шел на частоту шины проц-мамка-озу.
Олег
заметили 4кратное падение скорости при отключение dualchannel
Олег
в 4 раза
Олег
скажемс вместо 20 минут получались 60-80
Олег
отсюдова очень интересно было пощупать amd
Олег
с 8канальностью
Олег
мы тестили 4 и 6 каналов
Григорий
мы тестили 4 и 6 каналов
Это логично. Многие бенчмарки, например, гикбенч, то же раза в два меньше дают попугаев при неиспользование всех каналов ОЗУ.
Олег
у нас запись хаотичная 80%
Олег
после тестов на кликхаус ушли
Григорий
На сколько понял, ZFS какие-то таблицы кэширует в ОЗУ.
Олег
при базе данных же ssd
Олег
а ZFS только что начал адаптироваться
Олег
может полгода назад
Олег
но все равно гарантированные записи убивают производительность
Олег
база озу сама неплохо кушает
Олег
мы сейчас 512GB взяли на 4TB
Олег
А так кеши лишние в бд зло
Олег
база нехерово кешит в озу
Олег
если наложить кешь на кешь
Олег
то выходит накладные
Олег
что равно хреново
Олег
макс производительности на mdadm добился
Олег
и xfs
Олег
кстати
Олег
при активном read (70+%)
Олег
стоит уже менять кеши фс