Вакуум руками прибивали недавно?

kill-9

нет

ну теперь хоть понятно, чего делать

dd if=/dev/zero of=/var/lib/postgresql/9.6/main/pg_clog/04EC bs=256K count=1

Вакуум руками прибивали недавно?

А как это влияет?

А как это влияет?

Бывает бьется при этом статистика в таблицах pg_catalog и по ним нужно делать vacuum full

не понимаю связи

clog же вообще можно прибить, он по идее из wal должен восстановиться

неа. к сожалению на практике все не так

hot_standby_feedback = on ?

Я не очень хорошо разбираюсь во внутренностях постгреса, просто читаю ваши обсуждения. Что такое блоат? Дословный перевод понятен, что это такое в рамках постгреса - не знаю.

hot_standby_feedback = on ?

да

Я не очень хорошо разбираюсь во внутренностях постгреса, просто читаю ваши обсуждения. Что такое блоат? Дословный перевод понятен, что это такое в рамках постгреса - не знаю.

Это результат работы MVCC. Когда у вас строка удалена, на самом деле она не перестает существовать. Отсюда рост размеров таблицы. Для того чтобы удалять ненужные строки есть несколько механизмов: внутристраничная очистка, вакуум и полный вакуум. Эти механизмы удаляют физически строки. В двух словах так

Понял, спасибо

ERROR: could not access status of transaction 1321660374 DETAIL: Could not open file "pg_clog/04EC": No such file or directory.

а на мастере осталась этот файлик?

нет

я с мастера и показал

Я не очень хорошо разбираюсь во внутренностях постгреса, просто читаю ваши обсуждения. Что такое блоат? Дословный перевод понятен, что это такое в рамках постгреса - не знаю.

блот - это примерно фактический размер таблицы минус размер, который занимают живые строки

ERROR: could not access status of transaction 1321660374 DETAIL: Could not open file "pg_clog/04EC": No such file or directory.

есть подозрение откуда это взялось?

нет пока

и кстати слейв так и не попустило

потеря питания, параметр fsync, ядро, fs, опции монтирования?

и кстати слейв так и не попустило

что с ним не так?

потеря питания, параметр fsync, ядро, fs, опции монтирования?

потери питания не было fsync = on # uname -r 4.2.0-38-generic ext4 /dev/mapper/system-postgresql /var/lib/postgresql ext4 defaults 0 2

что с ним не так?

LA >= 50 последние несколько часов

synchronous_commit = on ?

да

а чем бакэенды занимаются? sudo gdb —batch —ex bt -p $pid

mb seq scan'ы пошли из-за блоатинга?

что-то я не уверен, что в руби тыкать gdb'ой - хорошая идея...

Почему тут советуют pg_repack, который использует жуткую магию и может привести к потере данных? pg_compator же безопаснее?

что-то я не уверен, что в руби тыкать gdb'ой - хорошая идея...

не в руби, а прям в backend postgresql (те что сейчас CPU бьют)

а

Почему тут советуют pg_repack, который использует жуткую магию и может привести к потере данных? pg_compator же безопаснее?

Это вы где то прочитали или из личного опыта? Теряли данные?

Почему тут советуют pg_repack, который использует жуткую магию и может привести к потере данных? pg_compator же безопаснее?

Багу с потерей данных пофиксили ещё в 2014-м году. Если у вас 1.2+ версия, то можно не переживать за это.

# sudo gdb --batch --ex bt -p 24939 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x0000558fa54c0d20 in hash_search_with_hash_value () #0 0x0000558fa54c0d20 in hash_search_with_hash_value () #1 0x0000558fa52e104b in ?? () #2 0x0000558fa52e18c1 in tbm_add_tuples () #3 0x0000558fa518503f in btgetbitmap () #4 0x0000558fa517f1b2 in index_getbitmap () #5 0x0000558fa52af317 in MultiExecBitmapIndexScan () #6 0x0000558fa52ae389 in MultiExecBitmapAnd () #7 0x0000558fa52aece0 in ?? () #8 0x0000558fa52a5ec1 in ExecScan () #9 0x0000558fa529ebb8 in ExecProcNode () #10 0x0000558fa529acfe in standard_ExecutorRun () #11 0x0000558fa53b7f28 in ?? () #12 0x0000558fa53b94ca in PortalRun () #13 0x0000558fa53b6643 in PostgresMain () #14 0x0000558fa513c3fb in ?? () #15 0x0000558fa535606b in PostmasterMain () #16 0x0000558fa513d142 in main ()

9.6 ? :)

Багу с потерей данных пофиксили ещё в 2014-м году. Если у вас 1.2+ версия, то можно не переживать за это.

с уст сняли. Спасибо)

паралельный сек скан? :)

да

и типа до недавнего времени все было ок? тоже с 9.6 тоже с включенным паралельным seq scan?

ну он видимо из коробки такой, конфиги с 9.5 никак не изменились

и типа до недавнего времени все было ок? тоже с 9.6 тоже с включенным паралельным seq scan?

ну вот сегодня утром началось внезапно, да

тоесть на 9.6 было все ок до недавнего времени?

да

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

и поэтому планер начал паралелить запросы

а clog то куда делся? :))

а вот это загадко

Багу с потерей данных пофиксили ещё в 2014-м году. Если у вас 1.2+ версия, то можно не переживать за это.

Магия с триггерами, переименованиями таблиц то никуда не делась. Вопрос в чем: чем лучше pg_repack по сравнению с pg_compactable, раз его все советуют?

Магия с триггерами, переименованиями таблиц то никуда не делась. Вопрос в чем: чем лучше pg_repack по сравнению с pg_compactable, раз его все советуют?

потому что работает :)

а clog то куда делся? :))

у меня терялся на 9.4 после принудительного сброса изменений на диск, остановки варварским методом вакуума (kill -9) и остановкой postgres-а. Они терялись на слейве. Но не на мастере

кстати что с pg_compactable умеет паралелиться?

Это решалось простым копированием директории на слейв

кстати что с pg_compactable умеет паралелиться?

Думаю, в случае запуска нескольких экземпляров, на разные таблицы/схемы/database, ничего плохого не случится. Но вообще, надобности не возникало пока что, т.к. гоняется каждую ночь

Prometheus + Grafana

лучше чем mamonsu ?

не знаю

в общем я запустил-таки вакуум фулл

репак там адски долго работает

хм

INFO: vacuuming "pg_catalog.pg_trigger" INFO: "pg_trigger": found 0 removable, 12 nonremovable row versions in 1 pages DETAIL: 10 dead row versions cannot be removed yet. CPU 0.00s/0.03u sec elapsed 0.03 sec. INFO: vacuuming "public.users" INFO: "users": found 389500 removable, 25880881 nonremovable row versions in 2155699 pages DETAIL: 340234 dead row versions cannot be removed yet. CPU 33.92s/65.32u sec elapsed 268.78 sec.

и на этом месте он стоит

к следующим таблицам не переходит

это так и надо?

посмотри может он стоит ожидает, если нет, то значит работает

ERROR: S client not available

это так и надо?

VACUUM вам полностью пересобирает таблицу + индексы и т д. Скорее всего она у вас большая. Займет некоторое время

ну он же вроде выдал уже вердикт по этой таблице

но к следующей не переходит

Лучше вы бы над конкретными таблицами проводили вакуум

он вроде сначала считает, потом вакуумит

ммм

то есть DETAIL: 340234 dead row versions cannot be removed yet. CPU 33.92s/65.32u sec elapsed 268.78 sec. это были только предварительные расчеты, а весь хардворк вот сейчас идет?

на самом деле вот это странно - 340234 dead row versions cannot be removed yet

все еще никаких сообщений

уже минут 20 наверное

то есть DETAIL: 340234 dead row versions cannot be removed yet. CPU 33.92s/65.32u sec elapsed 268.78 sec. это были только предварительные расчеты, а весь хардворк вот сейчас идет?

не уверен, надо код посмотреть

причем в пг_стат_активити куча автовакуумов

postgres=# select pid,query from pg_stat_activity; -[ RECORD 1 ]--------------------------------------- pid | 9937 query | autovacuum: VACUUM public.offer_descriptions -[ RECORD 2 ]--------------------------------------- pid | 10012 query | autovacuum: VACUUM public.cached_offers -[ RECORD 3 ]--------------------------------------- pid | 6957 query | vacuum full VERBOSE ; -[ RECORD 4 ]--------------------------------------- pid | 7066 query | autovacuum: VACUUM public.offers -[ RECORD 5 ]--------------------------------------- pid | 7194 query | select pid,query from pg_stat_activity;

он может ждать взятия блокировки еще

но 20 минут много

на самом деле вот это странно - 340234 dead row versions cannot be removed yet

вот я про это и говорил, что vacuum full может ничего не дать

это значит, что либо висит еще старая незакомитченная транзакция, либо prepared_xact незакомитченный, либо через слот xmin маленький передается

вот я про это и говорил, что vacuum full может ничего не дать

не не не. не об этом была речь) Речь была о том, что поможет обычный вакуум. Он не поможет, по причине битого clog. Скорее всего оттуда растут ноги невозможности прогнать вакуум фулл.

незакомиченных транзакций не наблюдается

а на репликах?

репликация через слоты?

попробуйте остановить репликацию и потом прогнать вакуум

репликация через слоты

на репликах ничего кроме моего запроса в стат_активити нет

попробуйте остановить репликацию и потом прогнать вакуум

не поможнт, если слот не дропнешь

оооо, перешел-таки к следующей таблице

INFO: vacuuming "public.user_subscriptions" INFO: "user_subscriptions": found 10318 removable, 42433538 nonremovable row versions in 407373 pages DETAIL: 4751 dead row versions cannot be removed yet. CPU 9.40s/23.22u sec elapsed 71.25 sec.

покажите select txid_current_snapshot(); на мастере

и опять остановился

postgres=# select txid_current_snapshot(); -[ RECORD 1 ]---------+----------------------- txid_current_snapshot | 7079374155:7079374155:

и pg_replication_slots

postgres=# select txid_current_snapshot(); -[ RECORD 1 ]---------+----------------------- txid_current_snapshot | 7079374155:7079374155:

ну тут вроде ок