Всем привет, вопрос такой. Каким образом ускорить восстановление базы из

архивов ?
Архивы могу передавать пачкой по хоть сколько гигов, нагрукза на диск в этот момент максимальная (ССД) доходит до 8 воркеров по 50 Мбит / сек.

Но сам процесс background worker читает / пишет на диск со скоростью не более 100 Мбит / сек.

bgwriter настроен и имеет следующие параметры:
bgwriter_delay: 10ms
bgwriter_lru_maxpages: 1000
bgwriter_lru_multiplier: 10.0

Мастер "плодит" валы где то около 20 GB в 20 минут.

Уж не hdd ли это?

Точно нет

--- /var/lib/postgresql/ (zfs vkcrawler37/subvol-478-disk-0) ioping statistics --- 36.2 k requests completed in 2.99 s, 8.84 GiB read, 12.1 k iops, 2.96 GiB/s generated 36.2 k requests in 3.00 s, 8.84 GiB, 12.1 k iops, 2.95 GiB/s min/avg/max/mdev = 56.1 us / 82.6 us / 461.9 us / 24.6 us

А как получилось, что один воркер получает wal всего лишь на 50МБит/с ?

Pgbackrest и его настройки. 8 воркеров запущенных на получение архивов, и они просто делят диск Итоговое около 400Мбит/с

Слушай, я тогда конфиг стэнда совсем не понял. У тебя сейчас pgbackrest льёт в рамках restore_command 400 на диск? И ты чем-то недоволен?

скоростью восстановления самого ПГ. Условно я загоняю 250 гигов за 10 минут, а ПГ жует их долго...

Так оно же однопоточное.

вот видимо тут и ответ, спасибо.

Подробностей очень мало, чтобы что-то посоветовать (даже версии PostgreSQL нет?)...

Можно и так начать. У реплики есть Pgbackrest. Реплика на ССД находится. Pgbackrest может передавать файлы многопоточно (архивы вал). А вот Postgresql 15 тормозит наполнение, и ответ выше - он просто однопоточный. То есть выходит что скорость мастера (без синх коммита) пока что быстрее, чем восстановление реплики.

> Каким образом ускорить восстановление базы из архивов ? Если проблема именно в "накате" WAL на реплике — есть несколько вариантов... Для начала, Вы смотрели на https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY (потенциально, это может дать существенный эффект)? > Но сам процесс background worker читает / пишет на диск со скоростью не более 100 Мбит / сек. Какой именно background worker? > bgwriter настроен и имеет следующие параметры: Вы бы лучше checkpointer настраивали, а не эту "радость" (причём, если возможно, начиная с primary).

Мне кажется у свежих постгресов есть аналог pg_prewarm для этапа recovery. Когда он делает readahead для блоков данных с диска, немного проглядывая WAL вперёд. Но что за параметр это контролирует и в 15 или в 16 версии он появился - не могу вспомнить.

> А вот Postgresql 15 тормозит наполнение, и ответ выше - он просто однопоточный. Что не значит, что его нельзя ускорить (см. выше). > То есть выходит что скорость мастера (без синх коммита) пока что быстрее, чем восстановление реплики. Да, такое нередко (?) случается... тем не менее, зачастую "вытащить" это можно.

https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY

> Какой именно background worker? background writer

Ясно. Тем более см. совет в том сообщении. ;)

спасибо, если реплика через "ББ" не взлетит пойду опробовать.

Ssd SATA-шные? Там случайно дефолтный prefetch не оставлен? (hdparm -a /dev/... , если есть lvm — то на него тожэ) Хотя это вроде для чтения, для записи не должно влиять...

Казалось бы, не такой там большой round-trip до диска, чтобы один воркер простаивал заметное врнмя.

Даже сейчас однопоточная запись по 4к относительно небыстрая.

1) Пишыте по 8к. 2) На тэстах по 8к оно у меня упирается в nvme.

В PCI-интерфейс? В софтварную архитектуру? У меня-то тоже упирается в NVME. Просто уровень упора гораздо ниже паспортного seq write

В доку по конкретному NVMe. (Но он тогда небыстр был. Типа гига с чем-то или около полутора).

Посмотрел статистику своих тестов. 1.5 Гб в 48 потоков по 4к

Там, повторюсь, не 5к было. Вроде 8. Или 16. (И нет, это не постгресом тэстировал).

> Если проблема именно в "накате" WAL на реплике — есть несколько вариантов... Для начала, Вы смотрели на https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY (потенциально, это может дать существенный эффект)? эффекта не дало, пробовал разные размеры ставить (1 MB / 4 / 16 / 32 ) > Какой именно background worker? background writer >Вы бы лучше checkpointer настраивали, а не эту "радость" (причём, если возможно, начиная с primary). было 40 минут, поставил 30 / 20 эффекта так же нет. Мастер быстрее создает WAL, чем реплика их проигрывает.

> эффекта не дало, пробовал разные размеры ставить (1 MB / 4 / 16 / 32 ) Это всё довольно мало, нет? К тому же, он точно работает вообще (на используемой OS/FS)? И как Вы измеряете (странно, если эффекта нет вообще)? > было 40 минут, поставил 30 / 20 эффекта так же нет. Довольно странно, если от этого эффекта совсем нет (могло стать и [ощутимо] хуже, например). ;( Разве что все checkpoints на primary происходят по max_wal_size, что уже плохо. Вы можете какие-то числа показать?

например какие числа показать ?

Те, по которым Вы сделали вывод, что эффекта нет, разумеется.

даже не знаю и с чего начать. Просто ничего не кажет к примеру реплика принимает текущий вал 00000200027B150000019 а мастер находится на создании: 000002000A7B150000019

Но это же не серьёзно, Вам не кажется? ;( Вы бы измерили отставание (или объём применённого WAL) за какой-то период до изменения настроек, и за тот же период (при той же нагрузке) после применения настроек, например.

могу пока только судить по "патрони" и отставание там на 1.4 ТБ

Да Вам же скорость / ускорение этого процесса нужны (т.е. вот эти вот путь объём [применённых] WAL / время и т.п). ;) Оно же не догонит (и не отстанет) мгновенно, в любом случае...