Comments 103
Правильно понял суть, что пришлось залезть в душу сервера и всё перелопатить, а в итоге самым правильным и простым решением оказалось накатить актуальные обновления?
Тут всё же важно сфокусироваться на правильной последовательности действий:
Залезли в душу сервера - нашли источник проблемы.
Проверили трекер ФС - нашли исправление.
Накатили исправление - получили профит.
Гораздо прискорбнее видеть, как люди в попытке исправить проблемы пытаются "сэкономить время" на шаге 1. Обновим подсистему Х! Помогло? Ой, не помогло. Обновим подсистему Y! Помогло? Ой, не помогло. И так повторять до бесконечности. Либо картинно развести руками: ох, какая сложная проблема, совсем ничего не помогает!
Симптомы бывают одни, а реально болит в совсем другом месте. И да, много проблем решается обновлением того или иного. Но чтобы найти что обновлять (а вариантов тут может быть слишком много включая железо), придётся разобраться в деталях происходящего. На первый взгляд описание тикета ZFS не имеет ничего общего с симптомами в PostgreSQL, а вот как оно вышло.
А почему был сделан выбор в пользу ZFS, а не BTRFS, который тоже вроде как умеет в копирование при записи? Интересно, там может быть такая же проблема с NUMA? Или куча других неожиданных нюансов?
Потому что БТР по сути заброшен. Красная шапка от него отказалась насколько помню. Реализации RAID5/6 там если и завезли то недавно. Ну и были кейсы с потерей данных.
Тот же ZFS в линуксе юзаю ещё со времён FUSE моделей лет 10 назад и потерь данных ни разу не было.
RedHat одновременно и от ZFS отказались )
Как понимаю, продвигают альтернативу - некий Stratis...
скорее xfs, стратис производная
За ZFS они никогда и не топили, особенно учитывая что лицензия CDDL не даёт его в ядро включить уже много лет. И не факт что эта проблема решится...
А Stratis это не файловая система, а попытка реализовать часть фич ZFS используя текущие подсистемы ядра и не только (XFS/LVM/DM/LUKS/...) и обернуть это всё удобным CLI/API
Это неправда, она активно развивается и стала ФС по умолчанию в 33 Федоре. https://btrfs.wiki.kernel.org/index.php/Changelog#By_version_.28linux_kernel.29
The
Btrfsfile system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be movingBtrfsto a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.The
Btrfsfile system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature.
Я не говорю что она не развивается, но в RHEL на ней судя по всему поставили крест.
То, что BTRFS стала дефолтной рутовой ФС в Федоре, говорит о то, что этому суждено измениться, а Оракл в своей системе, основанной на красношляпе и так рекомендует BTRFS: https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Btrfs-UEK6
Рекомендую ещё посмотреть (стр. 34): https://www.diva-portal.org/smash/get/diva2:822493/FULLTEXT01.pdf
И это было семь лет назад.
Ну, хорошо что кто-то за него топит, особенно учитывая что BTRFS как и ZFS родился внутри Оракла.
Ну и монополия по фичам ZFS наверное не играет ему на пользу. Если BTRFS догонит его (или уже?) то всем от этого будет только лучше - часто полезные фичи и идеи тянут друг у друга.
То, что BTRFS стала дефолтной рутовой ФС в Федоре, говорит о то, что этому суждено измениться
Я бы на самом деле не был так уверен. Федора всё же десктопный дистриб более, вот если они в CentOS это завезли то наверное уже какой-то знак...
А почему был сделан выбор в пользу ZFS, а не BTRFS
Так BTRFS вышла в production-ready дай боже года три назад, а OpenZFS (ранее -- ZFS on Linux и собственная адаптация на FreeBSD) стабильна уже больше десяти лет. И ZFS намного фичастее. Опять же, я пока не видел примеров больших (сотни и тысячи TB) разделов с BTRFS. Как она себя вести будет, чёрт её знает.
Тот, кто знает, как жрёт RAM'у ZFS (by design, кстати говоря, не говоря уж про какой-нить dedup, упаси вас сила интернета включать его!), на сотнях и тысячах терабайт её запускать не будет. А тот, кто запустит, узнает. )
Как ни странно, факт останется фактом — нормальной CoW до сих пор нет. И по факту, да, гонять базу на них, это про удобство, но не про оптимальность, потому что дублирование логики просто чудовищное получается — версионность, например, будет и у базы, и у файловой системы. Понятно, что это гибко и удобно. Но если вам нужно выжать максимум из железки, вы этим заниматься не должны по определению.
О, ну ZFS -- это вообще не про производительность. Во всяком случае на куче мелких файлов. Я в 2013, выбирая ФС под хранилище Zoneminder (он тогда видео хранил в виде отдельного JPEG'а на каждый кадр), погонял разные варианты и ужаснулся тому, насколько же ZFS on Linux тормозной на этом сценарии. Выиграл ReiserFS (правда, через пару лет пришлось сменить на EXT4 с отключённым журналом, потому что ReiserFS стала нестабильной на Ubuntu).
Не всё так однозначно. Просто CoW имеют свою специфику, её нужно понимать, и знать, где они хороши, а где — так себе. В частности, они уменьшают seek'и при записи, что для HDD просто прекрасно. Но это не решает проблему seek'ов при чтении, конечно же, а фрагментация растёт быстро, и неумолимо. И это не единственная проблема, конечно.
Ну строго говоря часть проблем с 2018 года были решены.
L2ARC уже персистентный как минимум.
С удалением vdev из raidz и его расширением тоже подвижки были, не помню в каком оно состоянии, но по-моему в 2.2 будет.
Ресильвер последовательный тоже решил проблему ребилдов (в обычном рейде ты вообще весь диск заливаешь с нуля, а тут только занятые блоки).
Ну и так далее... в любом случае - альтернатив никаких нет :)
>> Выиграл ReiserFS
На единичном диске ReiserFS так и остается лучшей системой.
$ zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
storage 300T 286T 13.7T - - 56% 95% 1.00x ONLINE -
И таких хостов много. И, поверьте, легко потянет и петабайт. Головой просто надо пользоваться - и будет ок.
А (бесплатных) альтернатив у ZFS просто нет. Какой бы она ни была. Ну вот такова реальность.
бгг. Мне тут особенно колонка FRAG нравится. А пул-то, ведь, не такой уж и старый, да? А дефрага нет, и не будет. Ну и забивка 95 % слабо стыкуется с лозунгом дружбы с головой. В большинстве случаев те, кто дружат с головой, ставят на такие (и бОльшие) объёмы CEPH. Прочие же только думают, что дружат. )
Мне тут особенно колонка FRAG нравится. А пул-то, ведь, не такой уж и старый, да? А дефрага нет, и не будет.
Здорово, что вам нравится FRAG ! Я думаю, это отличный повод почитать, что же она таки означает ;-)
А байки-бабайки про фрагментацию оставьте детей пугать. Ах, да, там же дальше еще байка-бабайка про 95% заполненного пула... Ну давайте.
Ну и забивка 95 % слабо стыкуется с лозунгом дружбы с головой.
Слабо стыкуется только воинствующее незнание и работа сложных систем. А еще вера в байки, астрологию, арбидол и тп =)
ставят на такие (и бОльшие) объёмы CEPH.
Сравнивать тёплое и мягкое - очень весело и забавно, но, если не возражаете, мы с вами на этом завершим.
И, поверьте, легко потянет и петабайт.
Дался вам этот петабайт — вот система (у того же Мотина, кстати), где таких петабайтов 20, и 1248 дисков в одном пуле: "… This particular system is about capacity -- ~20PiB raw on 1248 disks in one ZFS pool. …".
Посчитаем, сколько должно быть RAM для обслуживания такого пула, если исходить из правила «1 TB дискача — 1 GB рамы» — ?
Посчитаем! Для массива с 1 PiB (сырых) — 1 TiB RAM'ы. А там, напоминаю, 20 их.
Нет никаких требований "Х ОЗУ на ТБ", это тот же кеш, как и в любой другой ФС. Хотите держать больше кеша - увеличиваете его. В памяти нужна только мета - отдайте ей гигабайт 10 хоть на 10 петабайт и всё.
Хотите экономить и страдать на любой ФС - задушите её по памяти, в ZFS никто вам этого не мешает сделать.
Во, да, узнаю фанатов — «задушить можно, лол, любую файловую систему». Весь прикол в том, что ZFS вы задушите там, где XFS будет дышать полной грудью. )
И если кэшем файловых данных зачастую можно пренебречь, то внутренние структуры самой файловой системы, так просто из песни не выкинешь.
Xfs на петабайты чудесным образом работает без кеша метаданных? И её мета из lru кеша не вымывается тем же чудом?
Расскажите, пожалуйста, как без озу держать петабайты и дышать полной грудью на какой-то ФС.
И если кэшем файловых данных зачастую можно пренебречь, то внутренние структуры самой файловой системы, так просто из песни не выкинешь.В zfs можно отказаться от кеширования непосредственно файлов и оставить только метаданные через primarycache=metadata. Потребление ОЗУ тогда будет ничтожным, по сравнению со стандартным all.
В zfs можно отказаться от кеширования непосредственно файлов
Да можно, конечно, и отказаться. Более того, как я уже писал (вообще говоря, я использовал ZFS в Solars, FreeBSD и Linux), если включить primarycache=metadata, то и в L2ARC можно будет максимум только их (metadata) и получить. Кстати, надо было бы там упомянуть ещё и про неоптимальный расход диска при ashift=12, может допишу. ;-)
Ну так вот — если вспомнить о чём тут статья была, то она про Postgresql. Который (в отличие от MySQL's InnoDB) крайне полагается на кэш файловой системы, и для него рекомендация «отключить» будет означать жёсточайшую просадку производительности.
Вы recordsize 8k/16k когда-нибудь пробовали применять, например? В курсе, что для баз данных (и не только) это типичная рекомендация, потому что иначе будет дичайший write amplification? А в курсе, что будет происходить с потреблением памяти, когда терабайтный пул таких вот "8k" будет основательно заполнен? И да, я сейчас не про ARC, как тут некоторые пионеры вообразили.
Ну и как бы тут кто-то не пытался жопкой крутить, а зверский 1/4 RAM (ЕМНИП), как минималка ARC по-умолчанию, неспроста стоит. Потому что, опять же, иначе производительность пулов будет устраивать только пионерские файлопомойки, которыми они гордятся на хабрике. )
К примеру у меня на домашней файлопомойке при 16Тб места ажно 512М под ARC отрезано
Ну если ARC — это единственное, о чём хватает тяму рассуждать по теме использования памяти ZFS, то тут остаётся засвидетельствовать лишь потрясащей в своей убогости уровень (не)знаний, и порекомендовать хотя бы `slabtop` на свой файловой помойке запустить.
А потом сходить поплакать.
не говоря уж про какой-нить dedup, упаси вас сила интернета включать его!
а что не так с дедупликацией? просто нужно понимать применимость принятого в zfs подхода.
вот пример с реального сервера:
dedup: DDT entries 9863796, size 715B on disk, 230B in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 5.10M 20.4T 4.12T 3.86T 5.10M 20.4T 4.12T 3.86T
2 1.94M 7.76T 3.35T 3.13T 4.71M 18.8T 7.64T 7.15T
4 535K 2.09T 626G 586G 2.79M 11.2T 3.14T 2.94T
8 311K 1.21T 399G 373G 3.30M 13.2T 4.30T 4.02T
16 967K 3.78T 931G 872G 26.1M 104T 25.0T 23.4T
32 591K 2.31T 539G 506G 21.5M 85.8T 20.0T 18.7T
64 20.6K 82.3G 24.6G 23.0G 1.71M 6.86T 2.10T 1.97T
128 1.89K 7.57G 4.40G 4.11G 306K 1.19T 699G 653G
256 223 892M 683M 638M 77.1K 308G 235G 219G
512 39 156M 47.4M 44.3M 25.5K 102G 30.9G 28.9G
1K 13 52M 22.2M 20.8M 20.1K 80.2G 35.1G 32.8G
2K 33 128M 46.9M 43.9M 99.2K 388G 145G 136G
4K 4 16M 6.11M 5.71M 20.8K 83.2G 32.7G 30.6G
Total 9.41M 37.6T 9.93T 9.30T 65.7M 263T 67.4T 63.1Tтаблица дедупликации занимает в памяти 9863796 ⋅ 230 ≈ 2 ГБ, экономит более 50 ТБ на дисках.
что происходит если берется снапшот CoW для файлов базы данных, postgres как то гарантирует что данные не будут потеряны?
у баз обычно журналы есть. Поэтому по-факту будет откат до последней консистентной «версии», с который можно дальше догонять мастер, при желании.
Копирование на живую - это не атомарная операция, в отличии от взятия снэпшота и отката.
я говорю про то что для восстановленной из копии базы данных, если копирование было на уровне файлов — равнозначно запуску после аппаратной перезагрузки по reset, у CoW систем есть конечно бонус, защищающий данные от сбоев, но речь о вероятностях а не о гарантиях
Нормально — резервную копию базы данных делать средствами самой БД, настроив master-slave репликацию, в этом случае резервная копия будет не просто копией но и готовой к эксплуатации базой данных, и если позволяет железо, ее можно просто использовать как рабочую, пока идет восстановление основной машины.
ZFS CoW снепшот атомарен, моментален, не вызывает деградации производительности и не требует больших расходов. Гарантии есть.
В чём плюс такой схемы с ZFS снепшотам, что можно восстановиться на любой момент времени. Выбирается точка во времени, откатывается на снепшот перед точкой, а потом добираются WAL-ы которые лежат в следующем снепшоте. И делается recovery.
А и про бекапы - снепшоты инкрементально отправляются в СРК или на реплику ZFS-а через zfs send/receive. То есть можно держать 100500 снепшотов в СРК, а на мастере хранить за последние сутки.
А вот реплика - это не совсем безкап ибо она не позволяет восстановиться на точку в прошлом. Если кто-то дропнул таблицу или зашифровал ключевые блоки, то реплика окажется также поломанной.
wal_archive/wal_recieve + PITR позволяют перематывать состояние реплики, разве нет?
Про деградацию производительности — она там изначально, by design. Просто выглядит это обычно как небольшой налог, по сравнению с non-CoW, поэтому он до поры-до времени фанатами^W энтузиастами не замечается, а потом, бац — и приходит понимание, что за всё нужно платить. )
И я понимю, почему у зэтки так много фанатов среди пользователей BSD — просто у них файловой системы нормальной никогда не было. ) UFS традиционно тормоз, вторая версия, конечно, получше, но всё же даже не EXT4, и не XFS. Хаммерфс, Дилоном запиленный, вообще мало кто помнит (а он есть). Так что не, ZFS, конечно, ничё так, местами, но высоконагруженные базы данных это не её конёк.
"Места" сильно устарели, а местами просто никогда не были правдой.
<бгг>В вашем ответе, что характерно, конкретики не просто не хватает, её там просто нет вообще. В отличие от текста по ссылке.</бгг>
Ну так профактчекайте, вместо selection bias, статью.
Но это ж лень, это ж думать надо матчасть изучать. Сотни <бгг></бгг> не будут написаны! ;)
Замкнутый круг.
Вообще, пожалуй, этому стоит поблагодарить poige за пару минут здорового смеха. Все-таки, попикасту про NTFS все уже забыли: ту, в которой рекомендовалось отключать загрузку драйвера ntfs.sys, чтобы сэкономить 2 мегабайта памяти (особенно актуально для Vista и старше =) ). Последний раз она попадалась на глаз года три-четыре назад, и то: то ли на пикабу, то ли вообще на дётичке.
<бгг2>Пока всё как обычно — фанатики так и не осилили опровергнуть ни один из перечисленных в статье "ZFS is RAID5 of 2010s" тезисов, и пламени из заднеприводных сопел хватило только на обсуждение «человеческих нюансов», коих у себя они никогда заметить не были способны.</бгг2>
Трамвайный хам,
Админ куберов локалхоста
Матчасть не чёл
Но и не мог молчать, ведь
Три дня бежал он
Чтоб кричать вдогонку
"Смердит не от меня!"
Ну, во-первых, вас не спрашивали.
А во-вторых, ссылаться на собственную ангажированную статью, представляющую собой компиляцию всякого времен zpool_v28, собранную спустя столько лет после акутальности и уже на тот момент выдающую дыры в знании матчасти… ну, то такое.
Но, так и быть, давайте действительно пробежимся, раз есть время:
- Dedup. Результаты тестов где? Нету. Хотя бы умозрительные рассуждения зависимости размера DDT от volblocksize/recordsize, хоть что-нибудь, что выдало бы знание матчасти и/или фактический опыт? Нету. Бессмысленный вопль — есть. И что же тут предполагается опровергать?
- persistent L2ARC — вошло в 2.0, но об этом-то знают не только лишь все. Чего тут обратно опровергать?
- Reliability degradation on pool extension — поржал. А, типа, если вы решите собрать 0 из 5 и 6 — то все будет зашибись. Про расширение пула заменой дисков в онлайне вы скромно умолчали — цель-то была обгадить, а не в матчасти ковыряться.
- Recovery time Ну и от чего же оно зависит, а? Правильно, не от размера дисков, а от количества занятого места — спасибо голосу из зрительного зала! Кстати, там в 0.7, 0.8 и 2.0 навалили мешок оптимизаций в это дело — но это уже zpool_v5000 feature flags, а статья про zpool_v28.
- 4k drives poor support — еще смешнее, особенно, если развернуть утверждение. Потому что получится
назло мамке отморожу ушибуду использовать ashift=9 вместо 12 и страдать, потому что иначе не сказать, что zfs плохая!11адынадын. Т.е. вы и сами отлично понимаете "актуальность" этого пункта. - Single host FS — если это недостаток, то где статьи того же автора с таким же пунктом, обличающим xfs, extN, f2fs, reiserfs и прочих? А нетути! Снова мимо, та шо ж такое.
Всего один, видимо, случайно затесавшийся, справедливый пункт: отношение ARC/L2ARC к primary_cache=metadata. И то, и над этим ведутся работы.
Ну и что в этой коллекции лулзов и некомпетентности изобличать, право?
Разве что агрессивное хамье с лексиконом нифаната с 3Dnews.
ОК, я так спрошу -- вы пробовали средствами самой БД бэкапить 180Тб?
Прошу прощения за глупый вопрос. Если снапшотом снимать копию с постгри во время работы - копия будет консистентна? Белые люди так делают?
Делают.
Но database files и wal files должны быть в одном датасете.
Механизм, как этот понял, примерно таков:
Снепшот снимается всегда по границе транзакции, которая, в свою очередь, ограничена вызовом fsync. Если для БД выделен отдельный датасет, в который больше никто не пишет, то в момент снятия снепшота вы получаете консистентное состояние файлов с точки зрения самой БД (если не отключили в ней использование fsync, конечно).
Но даже если нет, все, что упало в wal, доиграется при запуске, а то что упало не до конца — будет отброшено.
Спасибо. А то собирал скриптами инструмент, который позволяет держать почасовые копии постгри почти так же удобно как MSSQL. Правда под винду. Сейчас запланировал переход на постгри на линуксе, а тот в свою очередь находится на zfs (lxc, чтобы избежать лишних слоёв виртуализации). Снапы поудобнее, чем ловить этот WAL. Попробую, в общем.
WAL можно ловить каким-нибудь syncthing даже.
А бинарную репликацию, кстати, не пробовали?
Не пробовал. Гугл тоже не в курсе, что за "бинарная репликация postgresql"
Может есть какие-то иные названия?
Нашёл. Это физическая. Да, пробовал. Без неё не знаю как ещё делать почасовые копии. Меня весь этот механизм удручает. А именно держать разные базы в разных службах Postgres для того, чтобы вести почасовые копии какой-то одной базы. Либо все базы будут в твоей копии, либо делай логическую. Я для себя пришёл к выводу, что просто надо заводить несколько постгресов под разные базы, и рисовать какую-то управлялку.
Да, она.
Тоже пришли к такому выводу: пока поднимаем дополнительные инстансы, по одному на базу.
Отдельно складываем снэпшоты zfs: суточный полный и диффы от него.
fsync тут ни при чём.
как только приложение сказало write, данные попали в цепкие лапы файловой системы. даже если они ещё не записаны на накопитель, файловая система уже работает с новой версией данных.
соответственно, снапшот неконсистентным быть не может (если, разумеется, в самой БД не накосячили).
fsync же нужен чтобы гарантировать консистентность данных на накопителе в случае внезапного отключения питания/ребута (в тот промежуток времени, когда данные уже были переданы фс, но только частично записаны на накопитель, из-за переупорядочивания операций можно словить разные любопытные эффекты)
Этот имел ввиду, что при работе БД fsync будет вызываться чаще, чем таймер сброса данных в транзакцию zfs.
Так же количество отдельных записей в файлы между двумя консистентными с ее точки зрения состояниями может быть равно количеству модифицированных страниц; для большой транзакции это миллионы.
Вызванный же на рабочий каталог fsync сообщает системе, что текущее состояние должно быть сброшено на диски — и управление вернется после того, как все слои хранилища отрапортуют об успешной записи, — разве нет?
Вызванный же на рабочий каталог fsync сообщает системе, что текущее состояние должно быть сброшено на диски — и управление вернется после того, как все слои хранилища отрапортуют об успешной записи, — разве нет?
так. но причём тут снапшоты? на них fsync никак на влияет
ЕМНИП, если не вырублен sync на датасете, то будет сформирован и выгружен txg, формируя новое консистентное состояние на диске. А снэпшот, являясь консистентным слепком, выдет выровнен во временной линии по этому состоянию.
Впрочем, и с sync=disabled оно будет так же, просто не все данные доедут сразу.
Нормально — резервную копию базы данных делать средствами самой БД, настроив master-slave репликацию, в этом случае резервная копия будет не просто копией но и готовой к эксплуатации базой данных, и если позволяет железо, ее можно просто использовать как рабочую, пока идет восстановление основной машины.
Реплика это не бэкап. Если кто-то сделает `DELETE FROM table` то реплика радостно это исполнит и данных не будет нигде.
я отлично понимаю что такое снапшоты, юзаю их давно с btrfs, и прекрасно знаю чем чреват master-slave репликация
просто я пользуюсь ими обоими, останавливаешь slave базу, делаешь снапшот файловой файловой системы где она лежит, запускаешь базу — репликация подтягивает накопивушюся разницу (в основном время тут — остановка базы чтобы завершить транзакции), в результате у тебя бонусы инкрементальных снапшотов (а btrfs их позволяет складывать в файл и использовать потом — дико удобно) и гарантия консистенции базы для ее восстановления
Вы про какую базу сейчас вещаете? В случае той же InnoDB, достаточно взять Percona XtraBackup (или её MariaDB'шное подобие) и безо всяких дисковых snapshot'ов получить и консистентый полный снимок базы, и инкрементальные понаделать.
Что не означает, что нельзя на Btrfs держать. Можно. Просто это значит, что этот setup больше про удобство, чем про быстродействие базы.
А вот когда у вас база размером в X терабайт, то бэкапить силами инструментов типа xtrabackup — смерти подобно.
\@
Для этого в «инструментах типа» есть режим инкрементального бэкапирования. Вы когда уже доки будете читать, вместо того, чтобы публиковать тут скудоумие своё(?)…
Именно. Так что RTFM. Да и вообще READ, ибо вон там выше, прежде, чем пыжиться отвечать на мой коммент, на который вот так вот получилось частично обгадиться, нужно открыть зенки пошире и узреть «Что не означает, что нельзя на Btrfs держать. Можно. Просто это значит, что этот setup больше про удобство, чем про быстродействие базы.»
А что касается восстановления убитых баз, то в нормальном проде, а не в вашей пионерии, есть набор реплик, на который трафик просто переключается. — Так что учиться надо, а не скудоумие своё на весь интернет демонстрировать.
Не надо OLTP решение использовать для аналитики. 180Тб уже стоит запихать в приспособленное для этого решение, коих масса.
ребята продают поддержку Postgres
странно от них ожидать рекомендацию использовать Clickhouse, Vertica, etc
В первую очередь не надо БД (не так важно какую) ставить на ФС с COW. Сама БД обеспечивает консистентность путем избыточной записи на диск. Добавляем сюда файловую систему на своем уровне обеспечивающую консистентность путем добавочной нагрузки на диски. А дополнительная нагрузка должна получаться нехилая - БД постоянно меняет одни и те же блоки, ФС старательно сохраняет все их версии. Postgres дополнительно еще сверху проходится autovacuum'ом еще раз меняя блоки и заставляя ФС писать их новый версии. Стоит ли такой оверхэд удобной возможности откатиться на некий снэпшот в прошлом?
Oracle не зря в свое время выпускала версию вообще без ФС - с прямым управлением дисками. БД в любом случае лучше знает что как и когда писать на диск, чем сторонний софт общего назначения.
Oracle не зря и выпускают подобные документы: https://www.oracle.com/technetwork/server-storage/solaris10/config-solaris-zfs-wp-167894.pdf
Мой камент относился к временам древних HDD, где критично для производительности было управлять какие куда в какой последовательности блоки записать.
Контроллер SSD это еще один слой абстракции, влияющий на общую производительность, такая себе ФС на железе. В целом время записи на SSD сильно меньше чем на HDD, но у SSD временами случаются существенные просадки скорости записи (перераспределение данных в сценарии когда мы циклически пишем/стираем данные) На этот случай оракл в экзадата придумали достаточно оригинальное решение - данные параллельно пишутся на HDD и SSD, транзакция считается завершенной по факту успешной записи на тот или иной диск, какой быстрее успеет записать.
>Её можно откатывать к предыдущим состояниям, так что можно даже обходиться без бэкапов
Феерично. На полуэкспериментальной FS без бэкапов. Данные должна жать и бэкапить СУБД.
На самом деле никогда не поверю, что нужно реально строить отчёты по 180ТБ. Вот прямо сразу по всем 180ТБ... Насколько знаю наша ERP (системообразующего предприятия) в несколько раз меньше занимает.
Феерично. На полуэкспериментальной FS без бэкапов. Данные должна жать и бэкапить СУБД.Если это база для анализа объединенной аналитики, то все данные получаются дублированы в отдельных базах и потеря этой аналитической базы может быть легко восстановлена из них. То есть исходные базы откуда сливают фактически и являются бэкапом интегрированной.
Базы нешуточные: две базы, в каждой по 180ТБ. В них сливаются данные из многих других, непостгресовых баз. А этими, огромными напрямую пользуются аналитики компании, и эта деятельность критически важная.
Ну, справедливости ради ZFS крайне стабилен и проблем с ним очень мало если использовать с умом. Использую его 10+ лет уже.
А аналитика по OLTP базе такого объема... да, идея сильно так себе. Кликхаус или Вертика решает с таком случае.
ZFS сжала эти базы в два раза — теперь каждая занимает на диске по 90 ТБ, железу бы вздохнуть с облегчениемА с чего бы должно стать легче?
количество независимых устройств стало меньше а нагрузка прежняя, значит средняя нагрузка на устройство — вырастает, это очень хорошо заметно на hdd дисках и когда нагрузка на базы — большая, затрагивающая сразу весь массив. С ssd так же но нагрузка, способная упереться в возможности ssd — сильная редкость.
Устройств там вполне могло остаться столько же, а за счёт сжатия мы уменьшаем количество IO (но это зависит от паттерна нагрузки) при этом увеличивая расходы на CPU (хоть и незначительно - LZ4 легко выдаёт гигабайты в секунду при распаковке).
А с чего бы должно стать легче?
С дисков нужно меньше читать.
А ссылку на скрипт можно получить pg_diagdump.sh ?
Долгоиграющие незавершённые транзакции не дают автовакууму вычистить «старые» данные
оказалось, что некоторым, рекордным транзакциям исполнилось уже 3 дня
сессии с состоянием idle in transaction ... Среди этих транзакций тоже нашилсь висевшие часами.
Тема долгоиграющих транзакций не раскрыта.
Очевидно, это вопросы к приложениям, а не к БД.
Процессоры работают вовсю, но вхолостую, а с точки зрения Postgres
транзакции проводят время в праздности (idle), и автовакуумы штурмуют
таблицы и индексы раз за разом.
Ну какой же тут idle?
Это либо ожидание чтения блоков, либо ожидание свободных блоков буферного
пула, либо ожидание сброса буфера лога.
И да, 180 Тбайт на PostgreSQL с аналитическими запросами... ну такое, на любителя.
>Итого: клиенту посоветовали перейти на свежие версии ZFS (2.1+)
Заодно можно и на zstd_compress перейти.
>Александр Мотин из компании iXsystems (США) наблюдал такое поведение на 40-ядерной машине под FreeBSD и сделал патч, который убирает лишние операции со счётчиками.
Статью только до aggsum дочитал и сразу вспомнил этот патч. Иногда полезно смотреть коммиты, issues и PR.
У меня был печальный опыт с ZFS + постгрес, база данных на 3 Тб. Вроде бы оно работает, но если запустить тяжелый запрос на несколько часов, система стабильно виснет намертво. После перезагрузки ZFS говорит, что все ОК и нормально монтируется, но база данных в хлам, постгрес вообще не запускается. Только бекапы спасали.
Глубоко копать не стали, перешли на UFS и все стало хорошо, даже по свободной памяти выиграли. Снапшотами не пользовались из-за ограничений по объему диска. Но они и не спасли бы, все равно часть транзакций потерялась бы.
Было это в 2017 году, возможно сейчас уже все починили, но пробовать еще раз смысла нет, работает - не трогай.
К подобным статьям нужно приводить настройки тюнинга ZFS в системе и PostreSQL (для ZFS).
Добрый день!
У Вас написано "Свой скрипт pg_diagdump.sh (по просьбе клиента его можно загрузить)", только не совсем понятно откуда его можно загрузить?
Была когда то мысль тоже большую базу (более 30TB) запихнуть в ZFS для сжатия, но решил попробовать timescaledb расширение задействовать его компрессию (детали https://www.timescale.com/blog/time-series-compression-algorithms-explained/), поскольку данные time siries это оказалось подходящее решение. В результате пожал данные более чем в 10 раз (пример https://twitter.com/vkukharik/status/1396827117976002560?s=61&t=-fTOgLwm9frBPcq560_sEA) и примерно во столько же уменьшилось время выполнения аналитических запросов (пример https://twitter.com/vkukharik/status/1397552808514179073?s=61&t=U-YnfyEoacmBtZ1qkWjOPQ) поскольку меньше сидели в disk I/O в пользу CPU (запаса ресурсов cpu было достаточно).
как выглядело сжатие 30+ ТБ? не думаю, что pg_dump + восстановление в чистую базу
timescale использует postgres для хранения данных и у них обоих есть свое сжатие (как на уровне данных так и на уровне таблеспейсов), их механизмы оказались хуже?
p.s. в btrfs есть поддержка zstd сжатия, которая заметно сильнее (и тюнится лучше) чем та что у zfs, почему выбрана именно zfs?
в btrfs есть поддержка zstd сжатия, которая заметно сильнее (и тюнится лучше) чем та что у zfs
а можно детали, почему zstd в btrfs может жать лучше, чем zstd в zfs?
Битвы на территории ZFS