-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PTRACK problem #596
Comments
Здравствуйте. Я вам скажу, что случилось: вы увеличили shared_buffers. Если уберёте жирный и увеличенный шрифт, объясню почему это так работает. Ну и, 150МБ ptrack.map_size может быть маловат. |
Хотя, может я не прав (но не на счёт жирного шрифта). Объясните, какой профиль нагрузки на эту базу? Она простаивает, или работает? Какой выставлен shared_buffers? Есть понятный сценарий воспроизведения, или это проявляется только на prod базе? Моё первое предположение было: на базе есть нагрузка. Когда пробэкап зовёт pg_start_backup, постгрес делает чекпойнт. ptrack помечает все сброшенные во время этого чекпоинта страницы, как записанные ПОСЛЕ pg_start_backup. Соответственно, когда берётся следующий инкремент, он считает изменёнными все эти страницы, и получается "толстый бэкап". При этом до этого следующего инкремента грязных страниц в shared_buffers оказывается не так много, во время его чекпоинта на диск пишется сотня мегабайт - и это именно то, что попадает в после-следующий "тонкий" инкремент. Безусловно, это гипотеза. Если есть сценарий воспроизведения, буду очень благодарен. |
Так, коллега дал подсказку, и кажется есть понимание. И это баг имени меня :-( Line 802 in d672166
Я добавил сравнение размеров для не-датафайлов. А в бэкапе, если файл не менялся, то размер записывается как -1. Соответственно, каждый второй бэкап сохраняются все не датафайлы. А это, в том числе, fsm и vm. Грустно :-( Попробуем воспроизвести и починить. |
Извиняюсь за паузу. По просьбе - убрал жирность письма =) Проверялась проблема и в нагрузке и в простое. Результат без разницы. shared_buffers = 2048MB ну и сразу, чтобы "два раза не вставать" другие параметры shared_buffers = 2048MB |
Должны починить в ветке REL_2_5 в 0690f8d |
pg_probackup --version было обновил (apt update && apt full-upgrade), стало продолжил прошлую 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 Итого - проблема осталась. ЗЫ: Почему у вас 2.5, а у меня 2.6 ? Или я не то обновил? |
@sorokindu потому что на Github у нас версия 2.5 Community, а у вас более новая сборка для Postgres Pro редакции Standard. |
Здравствуйте.
Запускаю
/
/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 так же себя ведёт =(
The text was updated successfully, but these errors were encountered: