Создавая из них пул я указал a shift 12

диски нарезаются на слайcы по 2^ashift

Ну да есть такое

а recordsize и volblocksize отщипывают этими слайсами

диски нарезаются на слайcы по 2^ashift

когда было 2**ashift - сказал бы что js программист )

ни в коем случае

когда было 2**ashift - сказал бы что js программист )

много где так

#вопрос Имеется такая разметка боевого сервера: root@167 ~ # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 223,6G 0 disk ├─sda1 8:1 0 8G 0 part │ └─md0 9:0 0 8G 0 raid1 [SWAP] ├─sda2 8:2 0 512M 0 part │ └─md1 9:1 0 511M 0 raid1 /boot └─sda3 8:3 0 215,1G 0 part └─md2 9:2 0 215G 0 raid1 ├─vg0-root 253:0 0 12G 0 lvm / ├─vg0-tmp 253:1 0 8G 0 lvm /tmp └─vg0-home 253:2 0 195G 0 lvm /home sdb 8:16 0 223,6G 0 disk ├─sdb1 8:17 0 8G 0 part │ └─md0 9:0 0 8G 0 raid1 [SWAP] ├─sdb2 8:18 0 512M 0 part │ └─md1 9:1 0 511M 0 raid1 /boot └─sdb3 8:19 0 215,1G 0 part └─md2 9:2 0 215G 0 raid1 ├─vg0-root 253:0 0 12G 0 lvm / ├─vg0-tmp 253:1 0 8G 0 lvm /tmp └─vg0-home 253:2 0 195G 0 lvm /homeесть ли какой-то пошаговый how-to по миграции на zfs с минимальным даунтаймом?

еще никак не могу побороть, при загрузке rpool bpool импортируются без проблем и все datasets с ними, а пул с raidz ни в какую не хочет, пока не впишу команду импорт в zfs-mount.service

Ребята у меня Ноды сожрали всю память с zfs

Память вернется или ограничивать?

Ребята у меня Ноды сожрали всю память с zfs

если не вызывает проблем и не приходит оом, то https://www.linuxatemyram.com/

А по русски

без ссылок

заббикс орет

вернется, как только понадобится. Если понадобится слишком резко и слишком много, ZFS может не успеть отдать, в этом случае можно добавить ограничения.

заббикс орет

у zfs дизайн такой - утилизация всей доступной памяти на благо скорости доступа к данным.

заббикс орет

мониторинг памяти видимо нужно делать сложнее, с учетом текущего потребления памяти ARC кэшем, небось такое уже кто-то сделал, погуглите

Заббикс орет - shutdown заббикс)))

вернется, как только понадобится. Если понадобится слишком резко и слишком много, ZFS может не успеть отдать, в этом случае можно добавить ограничения.

насколько знаю, зфс совсем неохотно отдаёт память - ни разу такого не видел.

насколько знаю, зфс совсем неохотно отдаёт память - ни разу такого не видел.

Умеет. Уже довольно давно

ну, может я старьём пользуюсь - иллюмос

а что является триггером к отдаче памяти?

а что является триггером к отдаче памяти?

запрос от процессов к ядру на выделение памяти?

маловероятно.

лиюо этот хук, который там повесили, тормозил бы всю систему

в ммапе который например

насколько знаю, зфс совсем неохотно отдаёт память - ни разу такого не видел.

отдаёт-отдаёт, ядро по хукам когда памяти мало просит освобождать. Конечно огромный кусок моментально не отдаст, но механизм рабочий

отдаёт-отдаёт, ядро по хукам когда памяти мало просит освобождать. Конечно огромный кусок моментально не отдаст, но механизм рабочий

буду знать, спасибо!

Не знаю как оно там внутри работает, но если запускать контейнеры в Proxmox один за одним на "поработавшем сервере", то график использования памяти резко упадет с ~90% до примерно 70%.. То есть мы запускаем новые контейнеры,а свободной памяти становится больше. Если посмотреть ARC кэш, он ожидаемо станет сильно меньше. С виртуалками прокатывает, только если стартовая. память для VM меньше оставшейся свободной памяти на сервере

ZFS возвращает память большими порциями.

Не знаю как оно там внутри работает, но если запускать контейнеры в Proxmox один за одним на "поработавшем сервере", то график использования памяти резко упадет с ~90% до примерно 70%.. То есть мы запускаем новые контейнеры,а свободной памяти становится больше. Если посмотреть ARC кэш, он ожидаемо станет сильно меньше. С виртуалками прокатывает, только если стартовая. память для VM меньше оставшейся свободной памяти на сервере

есть ещё засада, что qemu ожидает сразу начилия свободного озу, и с первого раза может не получиться

есть ещё засада, что qemu ожидает сразу начилия свободного озу, и с первого раза может не получиться

я уже сталкивался с этим)

ставил на чистку кеш внутри виртуалки и на целевом проксе, таким образом удавалось успешно мигрироваться

watch -n60 'sync; echo 3 > /proc/sys/vm/drop_caches'

вот так)

увы это и с другими ФС может быть, pagecache тоже не моментально может сработать емнип

Проще увеличить объем неприкосновенной памяти для ZFS до нескольких гб, чтобы на старт одной VM хватало наверное

вопрос

есть 2 снапшота можно ли востановить систему из первого

или обязательно удалять более новый

хочу восстановить первый, но потом примонтировать 2ой и перенести нужные данные

или это не возможно

есть 2 снапшота можно ли востановить систему из первого

Можно через клоны по идее

Можно через клоны по идее

А разве я не могу просто сделать снапы не скрытыми и тупо копирнуть от туда данные?

Без клонов

Я не пробовал так, но начитавшись теории у меня есть ощущение что так можно

А разве я не могу просто сделать снапы не скрытыми и тупо копирнуть от туда данные?

Можно конечно, это совсем в лоб и потребует больше места временно

Вчера сделал send в файл, а потом recive в dataset

Всем привет! У меня пул из hdd и только на special и slog ssd. Сейчас сделал autotrim=on и по субботам zpool trim в кроне. Стоит использовать trim ? В некоторых статьях пишут что это "опасно" даже. Можно и без трима спокойно жить

Всем привет! У меня пул из hdd и только на special и slog ssd. Сейчас сделал autotrim=on и по субботам zpool trim в кроне. Стоит использовать trim ? В некоторых статьях пишут что это "опасно" даже. Можно и без трима спокойно жить

опасно чем? autotrim=on может немного аффектить нагрузкой в момент срабатывания, в остальном всё должно быть ок

опасно чем? autotrim=on может немного аффектить нагрузкой в момент срабатывания, в остальном всё должно быть ок

аффектить да. Вот тут https://utcc.utoronto.ca/~cks/space/blog/linux/ZFSNoTrimForMeYet Человек беспокоится: TRIM разрушает данные по своей природе, а релаизация TRIM в Zol не вызывает доверия (не так давно вышла, мало протестирована), могут быть разные неожиданные ситуации и потеря данных с диска :) но это 2019 год. Сейчас уже не опасно ?)

а как часто autotrim срабатывает ?

аффектить да. Вот тут https://utcc.utoronto.ca/~cks/space/blog/linux/ZFSNoTrimForMeYet Человек беспокоится: TRIM разрушает данные по своей природе, а релаизация TRIM в Zol не вызывает доверия (не так давно вышла, мало протестирована), могут быть разные неожиданные ситуации и потеря данных с диска :) но это 2019 год. Сейчас уже не опасно ?)

ну запись уже устарела, да и человек не на конкретные проблемы ссылается а говорит что "хочу перебдеть", что для кода ФС логично. Если вы делаете бекапы (а вы же их делаете?:) ) то волноваться не о чем. Плюс от себя скажу, что за последний год критичных багов по trim я не помню

см. https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#trim плюс маны https://openzfs.github.io/openzfs-docs/man/8/zpoolprops.8.html

плюс код, если точно знать логику актуальную хочется

там не простая логика с набором кучки блоков под дальнейший трим

см. https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#trim плюс маны https://openzfs.github.io/openzfs-docs/man/8/zpoolprops.8.html

Спасибо огромное!!

всем привет! мы тестируем postgres (реплику с вал шипингом) на zfs (ubuntu 16.04,18.04) на GCP и нам похоже нехватет производительности zfs на запись (реплика отстает от мастера). Пока не удается найти какого ресурса не хватает: CPU <50% (ни один из процессов не занимает ядро даже на 50%), LA ~8 при кол-ве CPU 16, IOPS ~1500 (FIO дает 3-4k). Подскажите пожалуйста как можно понять чего не хватает и что нужно покрутить? ( zfs пул создан поверх всего диска)

всем привет! мы тестируем postgres (реплику с вал шипингом) на zfs (ubuntu 16.04,18.04) на GCP и нам похоже нехватет производительности zfs на запись (реплика отстает от мастера). Пока не удается найти какого ресурса не хватает: CPU <50% (ни один из процессов не занимает ядро даже на 50%), LA ~8 при кол-ве CPU 16, IOPS ~1500 (FIO дает 3-4k). Подскажите пожалуйста как можно понять чего не хватает и что нужно покрутить? ( zfs пул создан поверх всего диска)

iostat -dxm 5 10

диски в 100% по бизи не упирается

или что-то другое имеется в виду

что-то другое в том числе

2е тюнили postgresql? и не конкурируют ли у вас за ОЗУ постгрес и zfs?

всем привет! мы тестируем postgres (реплику с вал шипингом) на zfs (ubuntu 16.04,18.04) на GCP и нам похоже нехватет производительности zfs на запись (реплика отстает от мастера). Пока не удается найти какого ресурса не хватает: CPU <50% (ни один из процессов не занимает ядро даже на 50%), LA ~8 при кол-ве CPU 16, IOPS ~1500 (FIO дает 3-4k). Подскажите пожалуйста как можно понять чего не хватает и что нужно покрутить? ( zfs пул создан поверх всего диска)

какова цель использования zfs в gcp ?

все что можно со стороны postgres сделали (отключили синк, fullpagewrites, дали достаточно памяти buffers чтобы уменьшить запись)

>и не конкурируют ли у вас за ОЗУ постгрес и zfs? - как это можно понять?

>и не конкурируют ли у вас за ОЗУ постгрес и zfs? - как это можно понять?

в syctl вноситься сколько памяти будет отдано ZFS

И по симптомам вам perf бы поработать

> какова цель использования zfs в gcp ? - вся инфра в GCPнужно для функций ZFS по клонированию

пробовали perf смотреть - но у нас явно ожидания на запись а не на CPU (семплировали состояние процесса постгреса)

всем привет! мы тестируем postgres (реплику с вал шипингом) на zfs (ubuntu 16.04,18.04) на GCP и нам похоже нехватет производительности zfs на запись (реплика отстает от мастера). Пока не удается найти какого ресурса не хватает: CPU <50% (ни один из процессов не занимает ядро даже на 50%), LA ~8 при кол-ве CPU 16, IOPS ~1500 (FIO дает 3-4k). Подскажите пожалуйста как можно понять чего не хватает и что нужно покрутить? ( zfs пул создан поверх всего диска)

pg_testfsync на диск с pg сделайте и покажите

всем привет! мы тестируем postgres (реплику с вал шипингом) на zfs (ubuntu 16.04,18.04) на GCP и нам похоже нехватет производительности zfs на запись (реплика отстает от мастера). Пока не удается найти какого ресурса не хватает: CPU <50% (ни один из процессов не занимает ядро даже на 50%), LA ~8 при кол-ве CPU 16, IOPS ~1500 (FIO дает 3-4k). Подскажите пожалуйста как можно понять чего не хватает и что нужно покрутить? ( zfs пул создан поверх всего диска)

пул создавали с донастройкой под постгрю? конкретно хотя бы recordsize интересует, можете показать zfs get all POOL/DATASET к примеру

а так выше верно написали, смотрите iostat, zpool iostat

всем привет! мы тестируем postgres (реплику с вал шипингом) на zfs (ubuntu 16.04,18.04) на GCP и нам похоже нехватет производительности zfs на запись (реплика отстает от мастера). Пока не удается найти какого ресурса не хватает: CPU <50% (ни один из процессов не занимает ядро даже на 50%), LA ~8 при кол-ве CPU 16, IOPS ~1500 (FIO дает 3-4k). Подскажите пожалуйста как можно понять чего не хватает и что нужно покрутить? ( zfs пул создан поверх всего диска)

какой тип диска сделан для инстанса?

>пул создавали с донастройкой под постгрю? конкретно хотя бы recordsize интересует — пробовали 8к и 128к, именно накат логов быстрее идет при 8, 128 лучше в другой нагрузке вроде создание индексов, но даже 8к недостаточно быстро

> а так выше верно написали, смотрите iostat, zpool iostat — а что именно смотреть - все метрики далеки от 100%

> а так выше верно написали, смотрите iostat, zpool iostat — а что именно смотреть - все метрики далеки от 100%

для пула sync включен или выключен?

пробовал sync включенный и выключенный - нет разницы

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