Добрый день. Подскажите пожалуйста Ручной VACUUM (INDEX_CLEANUP OFF, TRUNCATE OFF) большой

append only таблицы весом в 9Тб вызывает кучу блокировок в том числе и Lock:extend для вставки в эту же таблицу.
Выставлены параметры:
vacuum_cost_delay: 25ms
vacuum_cost_limit: 3000
версия Postgres: 14.7

Как можно уменьшить влияние вакуума на перфоманс?
И правильно ли понимаю что для Lock:extend блокировок на вставку может влиять высокое значение shared_buffers?

А почему vacuum вообще делает extend ?

не вакуум, а последствия запущенного вакуума вызывают блокировки INSERT в эту таблицу с типом Lock:extend

> Ручной VACUUM ... вызывает кучу блокировок как вы это зафиксировали? глазами в pg_stat_activity или есть графики хорошо показывающие корреляцию роста при запуске вакуума?

графики по блокировкам + логи в момент запуска вакуума ну и логировал вывод pg_stat_activity с blocking.pid

о, а можете показать графики upd. а что в логах увидели? увеличение времени выполнения инсертов, появление waiting'ов или что-то еще?

эмм, это не совсем то что ожидал увидеть. надеялся увидеть именно вейт_ивенты (у вас на графике блокировки, но там пики на accessshare и rowshare это не критично, это самые лайтовые блокировки)

графика по lock:extend нет, Я временно логирую вывод SELECT now() AS datetime, blocked.pid, blocked.usename, blocked.query, blocking.pid AS blocking_id, blocking.query AS blocking_query, blocking.wait_event AS blocking_wait_event, blocking.wait_event_type AS blocking_wait_event_type FROM pg_stat_activity AS blocked JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid)); в таблицу и там заметил что во время запуска VACUUM как раз проявляются Lock:extend на вставку для этой таблицы

кстати вы в курсе что pg_blocking_pids имеет спецэффект? Note that execution of pg_blocking_pids() requires exclusive access to the lock manager's shared state for a short period, which may have performance implications, particularly if frequently called. попробуйте не запускать этот свой запрос на время наблюдения (тут интересно будут ли наблюдаться прежние всплески блокировок в графане) и второй момент по логам, я так и не понял, инсерты то встают в ожидание или нет? то есть, видите ли вы строки (при условии что включен log_lock_waits) типа: LOG: process 663 still waiting for .... after 1000.365 ms DETAIL: Process holding the lock: 660. Wait queue: 663. STATEMENT: INSERT ...; или просто выполнение инсертов но медленне чем обычно?

да и встают process 4014006 still waiting for ExclusiveLock on extension of relation 310611 Где prosecc holding the lock тот же INSERT но запущенный раньше

это виртуальный сервер?

CloudSql

возможно там очень жёстки лимит на IO и ввод/вывод от vacuum вытесняет боевой трафик

А полное blocking tree как выглядит в этом месте?

Ayan

а что в id 4014007?

что остается делать, дальше крутить vacuum_cost_delay и vacuum_cost_limit чтобы уменьшить влияние или еще и shared_buffers т.к по треду https://postgrespro.com/list/thread-id/2511548 это тоже влияет на вставку при Lock:extend?