172 похожих чатов

Коллеги, всем привет. Давно пользуемся постгресом (с 9.0), примерно месяц

назад перешли с 10 на 12.3 и в данный момент обнаружили странную проблему, с которой не можем разобраться. Будем благодарны за любую помощь в диагностике проблемы.

Есть кластер с 50 баз. Размеры таблиц в базах самые разные, от мегабайт до терабайт. Уже много времени исопльзуем однажды настроенный аггресивный autovacuum. Раньше он у нас постоянно шуршал и в какой то момент мы даже уменьшили количетсо воркеров чтобы снизить iowait в пиковые нагрузки. Количество активных воркеров автовакума мониторится и подстроенно чтобы они не были постоянно по максимуму загружены.

После грейда на 12 обнаружили что автовакум шуршит постоянно только в одной базе. Остальные базы не автовакумятся. Данный факт подтверждается в реалтайме по pg_stat_activity и по логам автовакума (log_autovacuum_min_duration=0 пишет логи только по одной базе). Время последнего автовакума/автоаналайза в pg_stat_user_tables по всем базам совпадает со временем когда приходил последний VACUUM to prevent wraparound. При этом количество активных воркеров не достигает максимального значения, те воркеры автовакума простаивают.


Например проблемная таблица в одной из баз
-[ RECORD 1 ]-------+------------------------------
n_tup_ins | 25599733
n_tup_upd | 2206685374
n_tup_del | 19938580
n_tup_hot_upd | 1863307770
n_live_tup | 186473676
n_dead_tup | 18177988
n_mod_since_analyze | 3250337
last_autovacuum | 2020-08-26 16:43:02.321971+03
last_autoanalyze | 2020-08-26 14:04:19.132566+03
vacuum_count | 1
autovacuum_count | 4078
analyze_count | 8
autoanalyze_count | 357

Настройки автокума
"autovacuum_max_workers" => 5,
"autovacuum_naptime" => "30s",
"autovacuum_vacuum_threshold" => 5000
"autovacuum_vacuum_scale_factor" => 0.00001
"autovacuum_vacuum_cost_delay" => "10ms"
"autovacuum_vacuum_cost_limit" => 6000,
"autovacuum_analyze_threshold" => 5000,
"autovacuum_analyze_scale_factor" => "0.01",

Плз подкиньте идей куда копать?

1 ответов

20 просмотров
Max-Vikharev Автор вопроса

В итоге после рестарта кластера проблема ушла и сразу пошел вакум по всем остальным базам. Зарепортил проблему в рассылку, но как воспроизводить не понятно, выглядит так как будто после vacuum to prevent wraparound автовакум зациклился на одной базе. Сделаем триггеры, будем ловить проблему снова.

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта