PTRACK problem

[sorokindu]

Здравствуйте.

Запускаю / /opt/pgpro/std-15/bin/pg_probackup backup --backup-path=/pg_probackup/ --instance=ksk-main --stream --backup-pg-log --temp-slot --compress --threads 4 -b ptrack / И, как результат, размер пляшет. Через раз, гигабайт накидывает. / BACKUP INSTANCE 'ksk-main' Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status ksk-main 15 RSU8TU 2023-04-09 12:59:00+05 PTRACK STREAM 1/1 48s 1438MB 16MB 1.00 BB/22000028 BB/22000A80 OK
ksk-main 15 RSU8SF 2023-04-09 12:58:09+05 PTRACK STREAM 1/1 40s 217MB 16MB 1.41 BB/20000028 BB/20000AB8 OK
ksk-main 15 RSSOAU 2023-04-08 16:37:57+05 PTRACK STREAM 1/1 30s 1439MB 16MB 1.00 BB/D000028 BB/D085D08 OK
ksk-main 15 RSSO8S 2023-04-08 16:36:42+05 PTRACK STREAM 1/1 27s 185MB 16MB 1.16 BB/B000028 BB/B05B3E0 OK
ksk-main 15 RSSLUQ 2023-04-08 15:45:10+05 PTRACK STREAM 1/1 28s 1436MB 16MB 1.00 BB/6000028 BB/6000A80 OK
ksk-main 15 RSSLTX 2023-04-08 15:44:34+05 PTRACK STREAM 1/1 24s 173MB 16MB 1.00 BB/4000028 BB/4000A80 OK
ksk-main 15 RSSLSP 2023-04-08 15:43:58+05 PTRACK STREAM 1/1 32s 1429MB 32MB 1.00 BB/2000028 BB/2000A80 OK
ksk-main 15 RSSLRO 2023-04-08 15:43:17+05 PTRACK STREAM 1/1 27s 163MB 32MB 1.07 BB/D8 BB/B30 OK
ksk-main 15 RSSL0D 2023-04-08 15:33:06+05 FULL STREAM 1/0 6m:43s 32GB 16MB 1.80 BA/FE014F48 BA/FEB88218 DONE
/ Настройки для PTRACK в postgresql.conf / shared_preload_libraries = 'online_analyze, plantuner, ptrack'
ptrack.map_size = 150
wal_level = replica / В данном конкретном случае, база ни как не изменяется. До этого, год проработало нормально. С примерными порциями в 150-200 МБ. Но, примерно, полгода назад, началось увеличение размера, через один бекап. Не понимаю, что случилось? Где искать причину?

ЗЫ: DELTA так же себя ведёт =(

[funny-falcon]

Здравствуйте.

Я вам скажу, что случилось: вы увеличили shared_buffers.

Если уберёте жирный и увеличенный шрифт, объясню почему это так работает.

Ну и, 150МБ ptrack.map_size может быть маловат.

[funny-falcon]

Хотя, может я не прав (но не на счёт жирного шрифта).

Объясните, какой профиль нагрузки на эту базу? Она простаивает, или работает?

Какой выставлен shared_buffers?

Есть понятный сценарий воспроизведения, или это проявляется только на prod базе?

Моё первое предположение было: на базе есть нагрузка. Когда пробэкап зовёт pg_start_backup, постгрес делает чекпойнт. ptrack помечает все сброшенные во время этого чекпоинта страницы, как записанные ПОСЛЕ pg_start_backup.

Соответственно, когда берётся следующий инкремент, он считает изменёнными все эти страницы, и получается "толстый бэкап". При этом до этого следующего инкремента грязных страниц в shared_buffers оказывается не так много, во время его чекпоинта на диск пишется сотня мегабайт - и это именно то, что попадает в после-следующий "тонкий" инкремент.

Безусловно, это гипотеза. Если есть сценарий воспроизведения, буду очень благодарен.

[funny-falcon]

Так, коллега дал подсказку, и кажется есть понимание. И это баг имени меня :-( https://github.com/postgrespro/pg_probackup/blob/d6721662ec76257d9470b1d20d75b7bc6bb1501c/src/data.c#L802 Я добавил сравнение размеров для не-датафайлов. А в бэкапе, если файл не менялся, то размер записывается как -1. Соответственно, каждый второй бэкап сохраняются все не датафайлы. А это, в том числе, fsm и vm.

Грустно :-(

Попробуем воспроизвести и починить.

[sorokindu]

Хотя, может я не прав (но не на счёт жирного шрифта).

Объясните, какой профиль нагрузки на эту базу? Она простаивает, или работает?

Какой выставлен shared_buffers?

Есть понятный сценарий воспроизведения, или это проявляется только на prod базе?

Моё первое предположение было: на базе есть нагрузка. Когда пробэкап зовёт pg_start_backup, постгрес делает чекпойнт. ptrack помечает все сброшенные во время этого чекпоинта страницы, как записанные ПОСЛЕ pg_start_backup.

Соответственно, когда берётся следующий инкремент, он считает изменёнными все эти страницы, и получается "толстый бэкап". При этом до этого следующего инкремента грязных страниц в shared_buffers оказывается не так много, во время его чекпоинта на диск пишется сотня мегабайт - и это именно то, что попадает в после-следующий "тонкий" инкремент.

Безусловно, это гипотеза. Если есть сценарий воспроизведения, буду очень благодарен.

Извиняюсь за паузу. Спасибо за ответ.

По просьбе - убрал жирность письма =)

Проверялась проблема и в нагрузке и в простое. Результат без разницы.

shared_buffers = 2048MB

ну и сразу, чтобы "два раза не вставать" другие параметры

shared_buffers = 2048MB temp_buffers = 128MB work_mem = 256MB maintenance_work_mem = 256MB max_files_per_process = 10000 max_parallel_workers_per_gather = 0 max_parallel_maintenance_workers = 2 commit_delay = 1000 max_wal_size = 4GB min_wal_size = 2GB checkpoint_timeout = 15min effective_cache_size = 6144MB from_collapse_limit = 8 join_collapse_limit = 8 autovacuum_max_workers = 2

[funny-falcon]

Должны починить в ветке REL_2_5 в 0690f8d10eef4926bbe236c88327be55eba242f2 Можете проверить, пожалуйста?

[sorokindu]

Должны починить в ветке REL_2_5 в 0690f8d Можете проверить, пожалуйста?

pg_probackup --version

было pg_probackup 2.6.0 community (Postgres Pro 15.2.1 standard) (compressions: zlib, pglz, lz4, zstd)

обновил (apt update && apt full-upgrade), стало pg_probackup 2.6.2 community (Postgres Pro 15.2.1 standard) (compressions: zlib, pglz, lz4, zstd)

продолжил прошлую ptrack серию. Без изменений. создал full архив. повторил ptrack серию. Без изменений. Все так же

Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status

ksk-main 15 RTTEOM 2023-04-28 12:41:20+05 PTRACK STREAM 1/1 14s 170MB 16MB 1.00 D1/D6000028 D1/D6000A80 OK ksk-main 15 RTTENU 2023-04-28 12:40:56+05 PTRACK STREAM 1/1 22s 1586MB 16MB 1.00 D1/D4000028 D1/D4000A80 OK ksk-main 15 RTTENC 2023-04-28 12:40:34+05 PTRACK STREAM 1/1 14s 170MB 16MB 1.00 D1/D2000028 D1/D2000A80 OK ksk-main 15 RTTEML 2023-04-28 12:40:10+05 PTRACK STREAM 1/1 22s 1578MB 16MB 1.00 D1/D0000028 D1/D0000A48 OK ksk-main 15 RTTELT 2023-04-28 12:39:45+05 PTRACK STREAM 1/1 23s 158MB 16MB 1.00 D1/CE000028 D1/CE000A80 OK ksk-main 15 RTTDO8 2023-04-28 12:25:03+05 FULL STREAM 1/0 6m:12s 32GB 32MB 1.79 D1/CC000028 D1/CC000A80 OK ksk-main 15 RTTDNK 2023-04-28 12:19:07+05 PTRACK STREAM 1/1 12s 190MB 32MB 1.00 D1/CA000028 D1/CA000A48 OK ksk-main 15 RTTDMR 2023-04-28 12:18:40+05 PTRACK STREAM 1/1 22s 1538MB 16MB 1.00 D1/C8000028 D1/C8000A48 OK ksk-main 15 RTTDMB 2023-04-28 12:18:21+05 PTRACK STREAM 1/1 11s 177MB 16MB 1.00 D1/C6000028 D1/C6000A48 OK ksk-main 15 RTTDLI 2023-04-28 12:17:54+05 PTRACK STREAM 1/1 22s 1538MB 16MB 1.00 D1/C4000028 D1/C4000A80 OK ksk-main 15 RTTDF3 2023-04-28 12:14:07+05 PTRACK STREAM 1/1 22s 170MB 16MB 1.00 D1/C2000028 D1/C2000A80 OK ksk-main 15 RTTBZW 2023-04-28 11:47:48+05 PTRACK STREAM 1/1 5m:37s 26GB 32MB 1.82 D1/C0000028 D1/C0000AB8 OK ksk-main 15 RSYDQR 2023-04-11 18:35:34+05 PTRACK STREAM 1/1 49s 194MB 16MB 1.32 BB/86000028 BB/86025070 OK ksk-main 15 RSXTPJ 2023-04-11 11:22:46+05 PTRACK STREAM 1/1 30s 1509MB 16MB 1.00 BB/79000028 BB/79000A80 OK ksk-main 15 RSXTCE 2023-04-11 11:14:54+05 PTRACK STREAM 1/1 31s 163MB 16MB 1.03 BB/77000028 BB/77000AB8 OK ksk-main 15 RSXS40 2023-04-11 10:50:21+05 DELTA STREAM 1/1 2m:52s 1503MB 32MB 1.01 BB/75000028 BB/750AB330 OK ksk-main 15 RSWJ25 2023-04-10 18:37:27+05 DELTA STREAM 1/1 2m:35s 178MB 16MB 1.47 BB/72000110 BB/722664D8 OK ksk-main 15 RSVYVL 2023-04-10 11:24:39+05 FULL STREAM 1/0 6m:25s 32GB 16MB 1.79 BB/5A000028 BB/5A000A80 DONE

Итого - проблема осталась.

ЗЫ: Почему у вас 2.5, а у меня 2.6 ? Или я не то обновил?

[Burus]

@sorokindu потому что на Github у нас версия 2.5 Community, а у вас более новая сборка для Postgres Pro редакции Standard.