второй делает ровно тоже самое через 30 сек после того как первый так сделал))

второй делает ровно тоже самое через 30 сек после того как первый так сделал))

делаю ставку на контроллер

они подключены на прямую к мамке)

на предыдущей мамке было тоже самое)

а бп у вас один и тотже был?

нет

ьп другой

от старого остался только проц и сами ssd

а замерьте тестером линию 5в поближе к винчестеру

Это SSD

там должно быть нениже 4,9

аааа

тогда отпадает

И кстати атм 6 сас дисков и из них никто не жалуется

они бы первые почуствовали проблемы

они подключены на прямую к мамке)

мамка той же модели? там же тоже контроллер

мамка той же модели? там же тоже контроллер

вот это даже не в курсе, вроде той же

они бы первые почуствовали проблемы

да, согласен

нашёл ошибку (numjobs не использовались фактически)

Всем привет

DRDY - drive ready. Это, скорее всего, проьлема sata

@banofbot

надо сюда этого бота добавить, очень помогает

У меня есть кое-что получше :)

Хотя вотебан тоже будет хорошим подспорьем

Я удивляюсь, как на это кто-то ещё ведётся :)

вот-вот

оно больше раздражает)

@neurox бот

@neurox бот

thnx

задрали уже

изучаю одного бота, завтра может уже попробую внедрить

@hornwind , @Laureldo боты?

Прям обидно-то как)))

Прям обидно-то как)))

Ни одной общей группы>)

@hornwind Миша, ты бот?

никак нет))

@hornwind Миша, ты бот?

А с ним четыре, но вопрос не снят

никак нет))

Норм🤝

Коллегу пригласил, чтобы читал и zfs преисполнялся))

Коллегу пригласил, чтобы читал и zfs преисполнялся))

🤝

В интернете набредал на заметки по поводу конфигурирования зфс и самого сервиса для максимальной производительности. Может, соберём какую-нибудь базу знаний?

Видел пг, мускуль, и ещё что-то

В интернете набредал на заметки по поводу конфигурирования зфс и самого сервиса для максимальной производительности. Может, соберём какую-нибудь базу знаний?

так она уже тут (в истории группы) есть. Нужно просто теперь пройтись по архиву и консолидировать. Но это же так лениво))))

Видел пг, мускуль, и ещё что-то

zvol для виртуалок (blocksize = размеру блока ФС, которая внутри ФС)

zvol для виртуалок (blocksize = размеру блока ФС, которая внутри ФС)

Либо 64 если кукау

У них кластер по 64 вроде

Не ошибаюсь?

qcow2 как файл для хранения ВМ - это по-моему моветон (особенно если qcow на zfs как файл). Рекомендации: zvol или lvm thin. В любом случае с qcow я пас - не работал, поэтому ничего не могу подсказать

Видел пг, мускуль, и ещё что-то

https://openzfs.org/wiki/Performance_tuning

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

https://openzfs.org/wiki/Performance_tuning

Шикарно!

https://openzfs.org/wiki/Performance_tuning

у меня вот это: PostgreSQL Make separate datasets for PostgreSQL's data and WAL. Set recordsize=8K on both to avoid expensive partial record writes. Set logbias=throughput on PostgreSQL's data to avoid writing twice. не "взлетело" оттуда. Латенси стал выше при таком режиме.

А транзакции шустрее стали при этом?

А транзакции шустрее стали при этом?

нет. В целом pg_bench меньше показал цифры

Странно. Может, вмешался кто. Кеш какой-нибудь, например

возможно их совет касался случая, когда нет SLOG. Или медленные диски. Но они этого не уточняют в рекомендации

Для пулов из быстрых дисков (ssd/nvme) я везде на датасетах оставил logbias=latency.

Для пулов из быстрых дисков (ssd/nvme) я везде на датасетах оставил logbias=latency.

соглашусь с тобой, вообще тема оптимизаций под БД не простая, очень много "если"

мне вообще интересно стало, переживёт ли постгря ребут, если на wal поставить sync=standard а на data sync=disabled, сможет ли оно корректно накатить логи и как быстро оно это делает

возможно их совет касался случая, когда нет SLOG. Или медленные диски. Но они этого не уточняют в рекомендации

а не мерил с recordsize=16k и compression=lz4?

латенси должно подрости, но thoughput по идее вырастет

С валами надо предельно осторожно

И врайт фулл пейджс неплохо б

а не мерил с recordsize=16k и compression=lz4?

у меня так и стоит по итогу для файлов самой СУБД. 16k и компрессия. Сжатие для баз получается где-то около x2. Для 1С баз получается выше - x2.8 А WAL-ы на отдельном в 128К. И я теперь их жму самим ПГ, поэтому компрессию(zfs) на датасете для валов отключил

у меня так и стоит по итогу для файлов самой СУБД. 16k и компрессия. Сжатие для баз получается где-то около x2. Для 1С баз получается выше - x2.8 А WAL-ы на отдельном в 128К. И я теперь их жму самим ПГ, поэтому компрессию(zfs) на датасете для валов отключил

почему кстати постгресом жмёшь? измерял разницу?

В общем вы смотивировали меня, тащу в гитхаб эту страницу, потом привлеку вас на открытие issues по теме

почему кстати постгресом жмёшь? измерял разницу?

более чем x3. Потому что у меня потоковая репликация идёт. И без компрессии валов стабильно занималось около 250-300мбит/с трафика, сейчас всё укладывается в среднем в 70-90мбит/с

более чем x3. Потому что у меня потоковая репликация идёт. И без компрессии валов стабильно занималось около 250-300мбит/с трафика, сейчас всё укладывается в среднем в 70-90мбит/с

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

сегодня подготовлю основу)

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

задокументировано это уже в разных местах), но с удовольствием выложу это и в общедоступные практики.

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

для случая с вм не совсем подходит ?

Убедил заказать всё таки 🙂

для случая с вм не совсем подходит ?

подходит и для ВМ, просто сжатие на уровне хоста уже будет меньше.

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

эта оптимизация особенно хорошо подходит, если WAL-ы нужно куда-то отправлять (архив, репликация)

Убедил заказать всё таки 🙂

хороший выбор), 👍

хороший выбор), 👍

Скоро моя vps полетит на славу 😁