Очень долгий autovacuum (to prevent wraparound) / PostgreSQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Очень долгий autovacuum (to prevent wraparound)

25 сообщений из 104, страница 3 из 5

все

Очень долгий autovacuum (to prevent wraparound)

#39192900

qwwq

Участник

Сообщения: 2 880

Рейтинг: 0 / 0

VerusK,

при примерно ~3*10^6 /час и объёме БД ~8ТБ имели проблемы с .
у вас объём почти на порядок меньше -- т.е. для аналогичных проблем рановато. если конечно в пики порядок по темпам ещё не делаете.

скажите девелоперам, чтобы избегали, по возможности, расставлять блоки обработки исключений на широких местах. какой-нть проверкой обходились бы. а блоки только в специально отведенных ветках, куда редко попадают. ибо каждый сейвпойнт -- прирост счётчика транзакций [RTFM "subtransaction"]

да, выводите не только age() но и сам frozentxid -- чтобы видеть, слистываются они у вас, или стоят на месте.

...

Рейтинг:

0 / 0

16.03.2016, 08:43

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39192905

VerusK

Гость

qwwq,

ок, учтем, я и есть разработчик, никак не DBA :)

Код: plsql

SELECT relname, age(relfrozenxid), relfrozenxid FROM pg_class WHERE relkind = 'r' order by age(relfrozenxid) desc;

выдает:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.

subscriptions_y2016_m1	479281498	456858465
pg_type	429281498	506858465
pg_authid	429281498	506858465
pg_attribute	429281498	506858465
pg_proc	429281498	506858465
pg_user_mapping	429281498	506858465
pg_attrdef	429281498	506858465
pg_constraint	429281498	506858465
pg_index	429281498	506858465
pg_operator	429281498	506858465
pg_opfamily	429281498	506858465
pg_opclass	429281498	506858465
pg_am	429281498	506858465
pg_amop	429281498	506858465
pg_amproc	429281498	506858465
pg_language	429281498	506858465
pg_aggregate	429281498	506858465
pg_rewrite	429281498	506858465
pg_trigger	429281498	506858465
pg_event_trigger	429281498	506858465
pg_description	429281498	506858465
pg_cast	429281498	506858465
pg_enum	429281498	506858465
pg_namespace	429281498	506858465
pg_conversion	429281498	506858465
pg_depend	429281498	506858465
pg_database	429281498	506858465
pg_db_role_setting	429281498	506858465
pg_tablespace	429281498	506858465
pg_pltemplate	429281498	506858465
pg_auth_members	429281498	506858465
pg_shdepend	429281498	506858465
pg_shdescription	429281498	506858465
pg_ts_config	429281498	506858465
pg_ts_config_map	429281498	506858465
pg_ts_dict	429281498	506858465
pg_ts_parser	429281498	506858465
pg_ts_template	429281498	506858465
pg_extension	429281498	506858465
pg_foreign_data_wrapper	429281498	506858465
pg_foreign_server	429281498	506858465
pg_foreign_table	429281498	506858465
pg_default_acl	429281498	506858465
pg_seclabel	429281498	506858465
pg_shseclabel	429281498	506858465
pg_collation	429281498	506858465
pg_range	429281498	506858465
pg_largeobject	429281498	506858465
sql_implementation_info	429281498	506858465
sql_languages	429281498	506858465
sql_packages	429281498	506858465
sql_sizing	429281498	506858465
sql_sizing_profiles	429281498	506858465
pg_class	429281498	506858465
cb_settings	429281498	506858465
pg_largeobject_metadata	429281498	506858465
pg_inherits	429281498	506858465
sql_features	429281498	506858465
sql_parts	429281498	506858465
inner_logs_y2016_m3	429281498	506858465
login_history	429281498	506858465
netspeed	429281498	506858465
clicks	429281498	506858465
subscriptions_y2016_m2	429281498	506858465
stats_y2016_m1	429281498	506858465
error_statistics	429281498	506858465
stats_referral	429281498	506858465
stats_y2016_m2	429281498	506858465
geo_indexes	429281498	506858465
translations	429281498	506858465
rebills	429281498	506858465
conversion_funnel	429281498	506858465
logs_y2016_m2	429281498	506858465
leads_y2015_m12	429281498	506858465
orders_y2015_m4	429281498	506858465
leads_y2016_m1	429281498	506858465
success_pages	429281498	506858465
leads_y2016_m3	429281498	506858465
orders_y2015_m7	429281498	506858465
orders_y2016_m2	429281498	506858465
orders_y2016_m1	429281498	506858465
leads_y2016_m2	429281498	506858465
inner_logs_y2016_m2	429281498	506858465
transactions	429281498	506858465
withdrawal_accounts	429281498	506858465
subscriptions_y2016_m3	429281498	506858465
orders_y2015_m9	429281498	506858465
orders_y2015_m10	429281498	506858465
stats_y2016_m3	429281498	506858465
orders_y2015_m12	429281498	506858465
accounts	429281498	506858465
offers_trafficback	429281498	506858465
orders_y2015_m8	429281498	506858465
orders_y2015_m5	429281498	506858465
ticket_answers	429281498	506858465
authtokens	429281498	506858465
countries_ranges	429281498	506858465
bp_service_codes	429281498	506858465
categories	429281498	506858465
browsers	429281498	506858465
logs	429281498	506858465
comebackers	429281498	506858465
postback_urls	429281498	506858465
currencies	429281498	506858465
rates_modifiers	429281498	506858465
subscriptions	429281498	506858465
currencies_rates	429281498	506858465
offer_targeting	429281498	506858465
subaccounts	429281498	506858465
tickets	429281498	506858465
stats	429281498	506858465
offer_settings	429281498	506858465
orders_y2014_m12	429281498	506858465
orders_y2015_m2	429281498	506858465
offers	429281498	506858465
pg_statistic	429281498	506858465
transaction_requests	429281498	506858465
orders	429281498	506858465
logs_y2016_m3	429281498	506858465
orders_y2016_m3	429281498	506858465
action_flows	429281498	506858465
advertiser_requests	429281498	506858465
blacklist	429281498	506858465
blog_categories	429281498	506858465
blog_posts	429281498	506858465
news	429281498	506858465
notifications	429281498	506858465
orders_y2015_m11	429281498	506858465
promo	429281498	506858465
mailing_lists	429281498	506858465
caps	429281498	506858465
conversion_types	429281498	506858465
countries	429281498	506858465
domains	429281498	506858465
goods	429281498	506858465
ip_geo_base	429281498	506858465
ip_ranges	429281498	506858465
offer_weights	429281498	506858465
operating_systems	429281498	506858465
operators	429281498	506858465
organizations	429281498	506858465
platforms	429281498	506858465
platforms_urls	429281498	506858465
prelandings_settings	429281498	506858465
rotators	429281498	506858465
settings	429281498	506858465
traffic_managers	429281498	506858465
traffic_redirect	429281498	506858465
traffic_sources	429281498	506858465
user_settings	429281498	506858465
user_types	429281498	506858465
users	429281498	506858465
leads	429281498	506858465
leads_y2014_m12	429281498	506858465
leads_y2015_m1	429281498	506858465
leads_y2015_m2	429281498	506858465
groups	429281498	506858465
leads_y2015_m3	429281498	506858465
leads_y2015_m4	429281498	506858465
leads_y2015_m5	429281498	506858465
leads_y2015_m6	429281498	506858465
leads_y2015_m7	429281498	506858465
leads_y2015_m8	429281498	506858465
leads_y2015_m9	429281498	506858465
leads_y2015_m10	429281498	506858465
leads_y2015_m11	429281498	506858465
orders_y2015_m6	429281498	506858465
prelandings	429281498	506858465
inner_logs	429281498	506858465
orders_y2015_m3	429281498	506858465
orders_y2015_m1	429281498	506858465
redress_history	429281498	506858465
submit_errors	429281498	506858465
sl_event	261300894	674839069
sl_confirm	261300894	674839069
sl_set	261300894	674839069
sl_subscribe	261300894	674839069
sl_nodelock	261300894	674839069
sl_seqlog	261300894	674839069
sl_log_script	261300894	674839069
sl_registry	261300894	674839069
sl_apply_stats	261300894	674839069
sl_config_lock	261300894	674839069
sl_setsync	261300894	674839069
sl_event_lock	261300894	674839069
sl_table	261300894	674839069
sl_sequence	261300894	674839069
sl_archive_counter	261300894	674839069
sl_components	261300894	674839069
sl_node	261300894	674839069
sl_listen	261300894	674839069
sl_path	261300894	674839069
clicks_y2016_m3	41490786	894649177
sl_log_2	820030	935319933
sl_log_1	275731	935864232

кстати, таблиц стало меньше в выводе, буквально вчера было 325, сегодня уже 195

...

Рейтинг:

0 / 0

16.03.2016, 08:50

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39192989

qwwq

Участник

Сообщения: 2 880

Рейтинг: 0 / 0

VerusK,

с чего у вас таблиц стало меньше ? вы фильтруете данные, а фильтры не приводите ?

эдак вашим словам грош цена.
т.е. всем.
т.е. совсем.

и да, вы всё время забываете о тостах. они немного отдельно фризятся.

где--то на просторах интернетов была вот такая заготовка

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

SELECT 
	pg_namespace.nspname
	,c.relname AS relname
	--,c.oid::regclass as table_name
	,greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age
	,c.relfrozenxid
	,t.relfrozenxid
FROM pg_class c
LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
LEFT JOIN 
	pg_namespace 
			ON pg_namespace.oid = c.relnamespace
WHERE c.relkind = 'r'
ORDER BY
	age desc
	,1,2;

...

Рейтинг:

0 / 0

16.03.2016, 10:28

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193014

VerusK

Гость

qwwq,

конечно не фильтрую, запрос как есть. Посмотрел вчерашний вывод, таблиц было 200 в выводе, в сегодняшнем 195

nspnamerelnameagerelfrozenxidrelfrozenxidpublicsubscriptions_y2016_m1482450377456858465506858465information_schemasql_features432450377506858465506858465information_schemasql_implementation_info432450377506858465506858465information_schemasql_languages432450377506858465506858465information_schemasql_packages432450377506858465506858465information_schemasql_parts432450377506858465506858465information_schemasql_sizing432450377506858465506858465information_schemasql_sizing_profiles432450377506858465506858465pg_catalogpg_aggregate432450377506858465pg_catalogpg_am432450377506858465pg_catalogpg_amop432450377506858465pg_catalogpg_amproc432450377506858465pg_catalogpg_attrdef432450377506858465506858465pg_catalogpg_attribute432450377506858465pg_catalogpg_auth_members432450377506858465pg_catalogpg_authid432450377506858465pg_catalogpg_cast432450377506858465pg_catalogpg_class432450377506858465pg_catalogpg_collation432450377506858465pg_catalogpg_constraint432450377506858465506858465pg_catalogpg_conversion432450377506858465pg_catalogpg_database432450377506858465pg_catalogpg_db_role_setting432450377506858465506858465pg_catalogpg_default_acl432450377506858465pg_catalogpg_depend432450377506858465pg_catalogpg_description432450377506858465506858465pg_catalogpg_enum432450377506858465pg_catalogpg_event_trigger432450377506858465pg_catalogpg_extension432450377506858465pg_catalogpg_foreign_data_wrapper432450377506858465pg_catalogpg_foreign_server432450377506858465pg_catalogpg_foreign_table432450377506858465pg_catalogpg_index432450377506858465pg_catalogpg_inherits432450377506858465pg_catalogpg_language432450377506858465pg_catalogpg_largeobject432450377506858465pg_catalogpg_largeobject_metadata432450377506858465pg_catalogpg_namespace432450377506858465pg_catalogpg_opclass432450377506858465pg_catalogpg_operator432450377506858465pg_catalogpg_opfamily432450377506858465pg_catalogpg_pltemplate432450377506858465pg_catalogpg_proc432450377506858465506858465pg_catalogpg_range432450377506858465pg_catalogpg_rewrite432450377506858465506858465pg_catalogpg_seclabel432450377506858465506858465pg_catalogpg_shdepend432450377506858465pg_catalogpg_shdescription432450377506858465506858465pg_catalogpg_shseclabel432450377506858465pg_catalogpg_statistic432450377506858465506858465pg_catalogpg_tablespace432450377506858465pg_catalogpg_trigger432450377506858465506858465pg_catalogpg_ts_config432450377506858465pg_catalogpg_ts_config_map432450377506858465pg_catalogpg_ts_dict432450377506858465pg_catalogpg_ts_parser432450377506858465pg_catalogpg_ts_template432450377506858465pg_catalogpg_type432450377506858465pg_catalogpg_user_mapping432450377506858465publicaccounts432450377506858465506858465publicaction_flows432450377506858465506858465publicadvertiser_requests432450377506858465506858465publicauthtokens432450377506858465506858465publicblacklist432450377506858465506858465publicblog_categories432450377506858465506858465publicblog_posts432450377506858465506858465publicbp_service_codes432450377506858465506858465publicbrowsers432450377506858465506858465publiccaps432450377506858465publiccategories432450377506858465506858465publiccb_settings432450377506858465publicclicks432450377506858465506858465publiccomebackers432450377506858465506858465publicconversion_funnel432450377506858465506858465publicconversion_types432450377506858465publiccountries432450377506858465506858465publiccountries_ranges432450377506858465publiccurrencies432450377506858465506858465publiccurrencies_rates432450377506858465506858465publicdomains432450377506858465506858465publicerror_statistics432450377506858465506858465publicgeo_indexes432450377506858465506858465publicgoods432450377506858465publicgroups432450377506858465506858465publicinner_logs432450377506858465506858465publicinner_logs_y2016_m2432450377506858465506858465publicinner_logs_y2016_m3432450377506858465506858465publicip_geo_base432450377506858465506858465publicip_ranges432450377506858465publicleads432450377506858465506858465publicleads_y2014_m12432450377506858465506858465publicleads_y2015_m1432450377506858465506858465publicleads_y2015_m10432450377506858465506858465publicleads_y2015_m11432450377506858465506858465publicleads_y2015_m12432450377506858465506858465publicleads_y2015_m2432450377506858465506858465publicleads_y2015_m3432450377506858465506858465publicleads_y2015_m4432450377506858465506858465publicleads_y2015_m5432450377506858465506858465publicleads_y2015_m6432450377506858465506858465publicleads_y2015_m7432450377506858465506858465publicleads_y2015_m8432450377506858465506858465publicleads_y2015_m9432450377506858465506858465publicleads_y2016_m1432450377506858465506858465publicleads_y2016_m2432450377506858465506858465publicleads_y2016_m3432450377506858465506858465publiclogin_history432450377506858465506858465publiclogs432450377506858465506858465publiclogs_y2016_m2432450377506858465506858465publiclogs_y2016_m3432450377506858465506858465publicmailing_lists432450377506858465506858465publicnetspeed432450377506858465publicnews432450377506858465506858465publicnotifications432450377506858465publicoffer_settings432450377506858465506858465publicoffer_targeting432450377506858465506858465publicoffer_weights432450377506858465506858465publicoffers432450377506858465506858465publicoffers_trafficback432450377506858465506858465publicoperating_systems432450377506858465506858465publicoperators432450377506858465506858465publicorders432450377506858465506858465publicorders_y2014_m12432450377506858465506858465publicorders_y2015_m1432450377506858465506858465publicorders_y2015_m10432450377506858465506858465publicorders_y2015_m11432450377506858465506858465publicorders_y2015_m12432450377506858465506858465publicorders_y2015_m2432450377506858465506858465publicorders_y2015_m3432450377506858465506858465publicorders_y2015_m4432450377506858465506858465publicorders_y2015_m5432450377506858465506858465publicorders_y2015_m6432450377506858465506858465publicorders_y2015_m7432450377506858465506858465publicorders_y2015_m8432450377506858465506858465publicorders_y2015_m9432450377506858465506858465publicorders_y2016_m1432450377506858465506858465publicorders_y2016_m2432450377506858465506858465publicorders_y2016_m3432450377506858465506858465publicorganizations432450377506858465506858465publicplatforms432450377506858465506858465publicplatforms_urls432450377506858465506858465publicpostback_urls432450377506858465506858465publicprelandings432450377506858465506858465publicprelandings_settings432450377506858465506858465publicpromo432450377506858465506858465publicrates_modifiers432450377506858465506858465publicrebills432450377506858465506858465publicredress_history432450377506858465506858465publicrotators432450377506858465506858465publicsettings432450377506858465506858465publicstats432450377506858465506858465publicstats_referral432450377506858465506858465publicstats_y2016_m1432450377506858465506858465publicstats_y2016_m2432450377506858465506858465publicstats_y2016_m3432450377506858465506858465publicsubaccounts432450377506858465506858465publicsubmit_errors432450377506858465506858465publicsubscriptions432450377506858465506858465publicsubscriptions_y2016_m2432450377506858465506858465publicsubscriptions_y2016_m3432450377506858465506858465publicsuccess_pages432450377506858465506858465publicticket_answers432450377506858465506858465publictickets432450377506858465506858465publictraffic_managers432450377506858465506858465publictraffic_redirect432450377506858465506858465publictraffic_sources432450377506858465publictransaction_requests432450377506858465506858465publictransactions432450377506858465506858465publictranslations432450377506858465506858465publicuser_settings432450377506858465506858465publicuser_types432450377506858465506858465publicusers432450377506858465506858465publicwithdrawal_accounts432450377506858465506858465_replicsl_apply_stats264469773674839069_replicsl_archive_counter264469773674839069_replicsl_components264469773674839069674839069_replicsl_config_lock264469773674839069_replicsl_confirm264469773674839069_replicsl_event264469773674839069674839069_replicsl_event_lock264469773674839069_replicsl_listen264469773674839069_replicsl_log_script264469773674839069674839069_replicsl_node264469773674839069674839069_replicsl_nodelock264469773674839069_replicsl_path264469773674839069674839069_replicsl_registry264469773674839069674839069_replicsl_seqlog264469773674839069_replicsl_sequence264469773674839069674839069_replicsl_set264469773674839069674839069_replicsl_setsync264469773674839069674839069_replicsl_subscribe264469773674839069_replicsl_table264469773674839069674839069publicclicks_y2016_m344659665894649177894649177_replicsl_log_21088538938220304938220304_replicsl_log_1153922939154920939154920

...

Рейтинг:

0 / 0

16.03.2016, 10:45

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193082

qwwq

Участник

Сообщения: 2 880

Рейтинг: 0 / 0

VerusK,

т.е. у вас что--то дропается.

т.к. свежие фризы таки есть -- у вас видимо просто собран большой бунч , который приходит на фриз одним большим куском. а чем он собран -- какой--то долгой транзакцией, вероятно. т.к. фрозентиксид расползтись не успели -- после этого ещё прокрутка эпохи фриза (2*10^8) не прошла.

у меня тоже есть жуткий комок:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.

WITH ages (age,c_relfrozenxid,t_relfrozenxid, size) AS
(
SELECT 
	--pg_namespace.nspname
	--,c.relname AS relname
	--,c.oid::regclass as table_name
	greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age
	,c.relfrozenxid
	,t.relfrozenxid
	,pg_table_size(c.oid::regclass)
FROM pg_class c
LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
LEFT JOIN 
	pg_namespace 
			ON pg_namespace.oid = c.relnamespace
WHERE c.relkind = 'r'
--ORDER BY 	age desc
	
)
SELECT age
	,min(c_relfrozenxid::text::bigint),min(t_relfrozenxid::text::bigint)
	,sum(size) AS total
	,pg_size_pretty(sum(size)) AS total_pretty
	,count(1) AS cnt FROM ages
GROUP BY 1
ORDER BY --age desc
	total DESC
;

строчек там 258, первая выглядит страшненько:
179604642320162621132016262112724595466240'2537 GB'566

-- придут на фриз 2.5 ТБ одним куском -- и будем мы "все в белом" опять.

...

Рейтинг:

0 / 0

16.03.2016, 11:24

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193107

VerusK

Гость

qwwq,

да, с виду как будто ушло 5 таблиц за несколько суток, скорость конечно атас
пугает еще то, что таблица по которой он сделал вакуум опять попала в вакуум
на работу БД пока что не влияет, но опять же варнинги в логах пугают, совсем не хочется аварийно съезжать на реплику, да и и если это реплика, то там ждать такого же поведения значит.

у меня это выдает вот такую картину:
434138884506858465506858465313794789376292 GB172484138884456858465506858465169881706496158 GB14634817289464917789464917742399334404044 MB12661582806748390696748390698927641685 MB191842429939154920939154920106496104 kB19387969400585539400585539830496 kB1

...

Рейтинг:

0 / 0

16.03.2016, 11:40

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193131

Alexius

Участник

Сообщения: 749

Рейтинг: 0 / 0

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

странно, а reload после правки конфига делался? должны записи о прошедших автовакуумах появляться.

...

Рейтинг:

0 / 0

16.03.2016, 11:58

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193134

VerusK

Гость

Alexius,

да, они начали появлятья, но чуть позже, вот несколько из них:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.

postgresql-Wed.log:2016-03-16 04:50:19 UTC   57351 LOG:  automatic vacuum of table "ho2.public.offers": index scans: 0
postgresql-Wed.log-	pages: 0 removed, 3588 remain
postgresql-Wed.log-	tuples: 0 removed, 28285 remain, 25635 are dead but not yet removable
postgresql-Wed.log-	buffer usage: 7924 hits, 263 misses, 4 dirtied
postgresql-Wed.log-	avg read rate: 0.093 MB/s, avg write rate: 0.001 MB/s
postgresql-Wed.log-	system usage: CPU 0.05s/0.03u sec elapsed 21.98 sec
--
postgresql-Wed.log:2016-03-16 04:50:42 UTC   839 LOG:  automatic vacuum of table "ho2.public.leads_y2016_m1": index scans: 0
postgresql-Wed.log-	pages: 0 removed, 18555 remain
postgresql-Wed.log-	tuples: 0 removed, 121061 remain, 0 are dead but not yet removable
postgresql-Wed.log-	buffer usage: 40542 hits, 17251 misses, 18 dirtied
postgresql-Wed.log-	avg read rate: 0.307 MB/s, avg write rate: 0.000 MB/s
postgresql-Wed.log-	system usage: CPU 0.55s/0.34u sec elapsed 439.38 sec
--
postgresql-Wed.log:2016-03-16 04:51:14 UTC   72430 LOG:  automatic vacuum of table "ho2.public.leads_y2016_m2": index scans: 0
postgresql-Wed.log-	pages: 0 removed, 31802 remain
postgresql-Wed.log-	tuples: 0 removed, 182815 remain, 0 are dead but not yet removable
postgresql-Wed.log-	buffer usage: 69537 hits, 26850 misses, 15 dirtied
postgresql-Wed.log-	avg read rate: 0.300 MB/s, avg write rate: 0.000 MB/s
postgresql-Wed.log-	system usage: CPU 0.96s/0.54u sec elapsed 698.14 sec
--
postgresql-Wed.log:2016-03-16 04:53:23 UTC   57351 LOG:  automatic vacuum of table "ho2.public.orders_y2015_m5": index scans: 0
postgresql-Wed.log-	pages: 0 removed, 13407 remain
postgresql-Wed.log-	tuples: 0 removed, 47603 remain, 0 are dead but not yet removable
postgresql-Wed.log-	buffer usage: 24729 hits, 6403 misses, 16 dirtied
postgresql-Wed.log-	avg read rate: 0.272 MB/s, avg write rate: 0.001 MB/s
postgresql-Wed.log-	system usage: CPU 0.18s/0.19u sec elapsed 183.77 sec
--
postgresql-Wed.log:2016-03-16 04:55:08 UTC   72430 LOG:  automatic vacuum of table "ho2.public.inner_logs_y2016_m2": index scans: 0
postgresql-Wed.log-	pages: 0 removed, 7391 remain
postgresql-Wed.log-	tuples: 0 removed, 155140 remain, 0 are dead but not yet removable
postgresql-Wed.log-	buffer usage: 7671 hits, 10437 misses, 6 dirtied
postgresql-Wed.log-	avg read rate: 0.349 MB/s, avg write rate: 0.000 MB/s
postgresql-Wed.log-	system usage: CPU 0.16s/0.18u sec elapsed 233.33 sec
--
postgresql-Wed.log:2016-03-16 04:55:42 UTC   72430 LOG:  automatic vacuum of table "ho2.public.transactions": index scans: 0
postgresql-Wed.log-	pages: 0 removed, 8092 remain
postgresql-Wed.log-	tuples: 0 removed, 236406 remain, 0 are dead but not yet removable
postgresql-Wed.log-	buffer usage: 16880 hits, 1 misses, 1 dirtied
postgresql-Wed.log-	avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
postgresql-Wed.log-	system usage: CPU 0.12s/0.07u sec elapsed 34.70 sec

...

Рейтинг:

0 / 0

16.03.2016, 12:00

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193148

Alexius

Участник

Сообщения: 749

Рейтинг: 0 / 0

VerusK,

хм, скорость никакая совсем. попробуйте autovacuum_vacuum_cost_delay (именно autovacuum, а не просто vacuum) снизить до 5ms.

...

Рейтинг:

0 / 0

16.03.2016, 12:08

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193190

VerusK

Гость

Alexius,

после изменения:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

2016-03-16 09:47:06 UTC   2831 LOG:  automatic vacuum of table "ho2.public.orders_y2016_m2": index scans: 0
	pages: 0 removed, 73112 remain
	tuples: 0 removed, 379330 remain, 37980 are dead but not yet removable
	buffer usage: 161944 hits, 38374 misses, 11 dirtied
	avg read rate: 0.295 MB/s, avg write rate: 0.000 MB/s
	system usage: CPU 1.27s/0.97u sec elapsed 1017.18 sec
--
2016-03-16 09:47:19 UTC   7699 LOG:  automatic vacuum of table "ho2.pg_toast.pg_toast_9328999": index scans: 0
	pages: 0 removed, 9728 remain
	tuples: 0 removed, 50207 remain, 1 are dead but not yet removable
	buffer usage: 19613 hits, 13 misses, 3 dirtied
	avg read rate: 0.002 MB/s, avg write rate: 0.000 MB/s
	system usage: CPU 0.09s/0.04u sec elapsed 51.06 sec

...

Рейтинг:

0 / 0

16.03.2016, 12:48

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193318

VerusK

Гость

qwwq,

т.е. надо просто ждать пока оно провернет этот кусок? очень страшно, что не успеет :)

...

Рейтинг:

0 / 0

16.03.2016, 14:36

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193780

VerusK

Гость

только что было очень странно, начался автовакуум для таблицы заново, до этого длившийся 1200+минут, но нет в логах ничего о завершении предыдущего

...

Рейтинг:

0 / 0

16.03.2016, 19:54

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193794

Alexius

Участник

Сообщения: 749

Рейтинг: 0 / 0

VerusK,

а в логах нет строки вида canceling autovacuum task ? некоторые блокировки могут автовакуум прибивать.

...

Рейтинг:

0 / 0

16.03.2016, 20:28

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39193813

VerusK

Гость

Alexius,

нет, ничего похожего не увидел. Зато есть вот такие записи:

Код: plsql

1.
2.

2016-03-16 17:47:26 UTC   86004 DEBUG:  transaction ID wrap limit is 2604342112, limited by database with OID 19489
2016-03-16 17:47:26 UTC   86004 DEBUG:  MultiXactId wrap limit is 2147483648, limited by database with OID 19489

...

Рейтинг:

0 / 0

16.03.2016, 20:51

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194149

qwwq

Участник

Сообщения: 2 880

Рейтинг: 0 / 0

VerusKqwwq,

т.е. надо просто ждать пока оно провернет этот кусок? очень страшно, что не успеет :)во первых "не успеет" это где--то около 4ярдов. (пессимистически, если только половина целого -- 2 ярда). а у вас возрасты всего то 0.5 ярда.

во вторых, я думаю, что , после того как бунч первый раз пролезет весь через воркеры -- его неплохо дополнительно растащить "по оси заморозки" ручными фризами.

и в третьих -- "много думал" -- и решил, что т.к. автовакуум работает с тостами и табличками раздельно -- нужно иначе оценивать комкование :

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.

deallocate all;
PREPARE FOO(integer) AS (

WITH tabs (age_grp,age,relfrozenxid,size) AS (
SELECT 
	--pg_namespace.nspname
	--,c.relname AS relname		
	(age(c.relfrozenxid)) / $1 as age_grp
	,(age(c.relfrozenxid)) as age
	,c.relfrozenxid
	--,pg_table_size(c.oid::regclass)
	,pg_relation_size(c.oid::regclass)
FROM pg_class c
LEFT JOIN 
	pg_namespace 
			ON pg_namespace.oid = c.relnamespace
WHERE c.relkind IN ('r','t')
)
SELECT 
	age_grp * $1 AS age_grp
	,min(age)  , max(age) 
	,min(relfrozenxid::text::bigint) AS relfrozenxid
	,SUM(size) AS sum_size
	,pg_size_pretty (SUM(size))
	,count(1)
FROM tabs 
GROUP BY 1 -- нужен "range", т.е. скользящая, но за неимением горничной
ORDER BY 3 DESC
);
EXECUTE FOO (3141592);-- характерное количесвто транзакций, за среднее время вакуума большой партиции. среднепотолочно

что даёт мне гораздо более оптимистическую оценку

Код: sql

197920296;198097056;200687136;3188185417;819149365248;'763 GB';115

т.е. ко мне пришли сейчас, в т.ч., 2 большие партиции, максимум их будет 3. все воркеры забиться не должны. но подсобрать ещё хвостов из следующей пачки бунч может. (простая волна с отрицательной нелинейностью укручается кзади. -- типичная "дорожная пробка", в которую впиливаются догоняющие)

...

Рейтинг:

0 / 0

17.03.2016, 11:02

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194158

VerusK

Гость

qwwq,

у меня цифры получились примерно те же:
537212232537636664537636664456858465169613049856"158 GB"1486946760487636664487636664506858465325679407104"303 GB"29397389352998459529984595289464917711825094656"11 GB"20146604814660489930290812834432"2768 kB"2

меня очень смущает то, что он начинает по кругу автовакуумить одну и ту же таблицу, у нас она самая большая, примерно 240млн строк. Зачем он это делает?

...

Рейтинг:

0 / 0

17.03.2016, 11:16

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194173

qwwq

Участник

Сообщения: 2 880

Рейтинг: 0 / 0

VerusK,

следите не за возрастом, а за фрозентхайди -- если он после цикла не сменился , или сменился очень мало (а многодневных длинных транзакций на момент старта не было) -- начинайте бурную эпиляцию пятой точки.
т.е. готовьте новый инстанс, с новой минорной, и переползайте на него.
//и начинайте писать по адресу -- т.е. в postgresql.org

если фрозенайди таки меняется , оцените по вашей цифре "темпа прироста транзакций" насколько стареет таблица за время отработки фриза по ней. сравнивайте с полученным age(). чешите тыковку.

я так думаю.

и да , все время мониторьте длинные транзакции в стат--активити.

...

Рейтинг:

0 / 0

17.03.2016, 11:32

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194206

VerusK

Гость

qwwq,

похоже, что он не меняется совсем, вот данные вчерашние:

Код: plsql

public	leads_y2015_m9	432450377	506858465	506858465

вот данные сегодняшние:

Код: plsql

public	leads_y2015_m9	488912641	506858465	506858465

похоже все плохо?

...

Рейтинг:

0 / 0

17.03.2016, 11:55

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194220

qwwq

Участник

Сообщения: 2 880

Рейтинг: 0 / 0

VerusK,

1. вы уверены, что фриз завершился ? (с фризом такая шняга -- его нельзя сделать "по частям". по крайней мере пока нет карты полностью отфриженных блоков)

2. вы уверены, что он (оба последних, завершившихся раза) стартовал в момент, когда у вас не висела одна и та же недельная транзакция в стат_активити ? т.е. вы _в тот_ момент мониторили наличие висяков ?

-- если оба ответа "да" -- начинайте добычу шерсти.

если не уверены -- то навешивайте мониторинг. При следующем "окончании фриза" без сдвига фрозена -- просто снимите табличку с автовакуума, и запустите VACUUM FREEZE руками. прямо на сервере. скажем в screen-е.

...

Рейтинг:

0 / 0

17.03.2016, 12:06

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194252

vyegorov

Участник

Откуда: Баньоло-ин-Пьяно

Сообщения: 1 237

Рейтинг: 0 / 0

VerusK,

1. Я вам давал запрос для проверки сессий. Вы что-то им сотрели?

2. Максим указал на проверку реплик. С ними всё в порядке? — работают, не отстают, не блокируют.

3. Какая у вас транзакционная активность?

Смотреть так

Код: sql

A=$(psql -qAtXc "SELECT txid_current()"); sleep 300; B=$(psql -qAtXc "SELECT txid_current()"); echo $(( ($B-$A)/5 )) $(( (($B-$A)/5)*60 ))

4. Какие настройки по проблемной таблице?

Смотреть так

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.

SELECT r.oid, r.relname, r.relpages, r.reltuples, s.name, coalesce(custom, setting) setting, s.boot_val
  FROM pg_class r
  JOIN pg_settings s ON s.name ~ 'vacuum'
  LEFT JOIN (
    SELECT pg_class.oid, split_part(o.opt,'=',1) opt, split_part(o.opt,'=',2) custom
      FROM pg_class
      LEFT JOIN unnest(reloptions) o(opt) ON 1=1) x ON x.opt=s.name AND r.oid=x.oid
 WHERE r.oid='attachments'::regclass
 ORDER BY relname, name;

5. Смотрите на `autovacuum_vacuum_cost_delay` / `vacuum_cost_delay` — делайтие минимальными.

6. Сделайте `vacuum_freeze_min_age` равным значению из #3 в час, умноженному на 4 часа — обычные вакуумы будут частично фризить данные. Но это на долгосрочную перспективу.

...

Рейтинг:

0 / 0

17.03.2016, 12:29

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194284

VerusK

Гость

vyegorov,

1. pgsql.sess.totalpgsql.sess.idlepgsql.sess.idlexidpgsql.sess.activepgsql.sess.waitingpgsql.sess.age[15s]pgsql.sess.age[60s]pgsql.sess.age[300s]pgsql.sess.age[600s]pgsql.sess.age[1800s]pgsql.sess.age[3600s]pgsql.sess.age[max]38133624211122141934146

2. Да, реплика работает нормально
3. 33629, 2017740
4. oidrelnamerelpagesreltuplesnamesettingboot_val7121865subscriptions_y2016_m120704718243768384autovacuumonon7121865subscriptions_y2016_m120704718243768384autovacuum_analyze_scale_factor0.10.17121865subscriptions_y2016_m120704718243768384autovacuum_analyze_threshold50507121865subscriptions_y2016_m120704718243768384autovacuum_freeze_max_age2000000002000000007121865subscriptions_y2016_m120704718243768384autovacuum_max_workers2037121865subscriptions_y2016_m120704718243768384autovacuum_multixact_freeze_max_age4000000004000000007121865subscriptions_y2016_m120704718243768384autovacuum_naptime60607121865subscriptions_y2016_m120704718243768384autovacuum_vacuum_cost_delay1207121865subscriptions_y2016_m120704718243768384autovacuum_vacuum_cost_limit-1-17121865subscriptions_y2016_m120704718243768384autovacuum_vacuum_scale_factor0.20.27121865subscriptions_y2016_m120704718243768384autovacuum_vacuum_threshold50507121865subscriptions_y2016_m120704718243768384autovacuum_work_mem-1-17121865subscriptions_y2016_m120704718243768384log_autovacuum_min_duration1000-17121865subscriptions_y2016_m120704718243768384vacuum_cost_delay107121865subscriptions_y2016_m120704718243768384vacuum_cost_limit2002007121865subscriptions_y2016_m120704718243768384vacuum_cost_page_dirty20207121865subscriptions_y2016_m120704718243768384vacuum_cost_page_hit117121865subscriptions_y2016_m120704718243768384vacuum_cost_page_miss10107121865subscriptions_y2016_m120704718243768384vacuum_defer_cleanup_age007121865subscriptions_y2016_m120704718243768384vacuum_freeze_min_age50000000500000007121865subscriptions_y2016_m120704718243768384vacuum_freeze_table_age1500000001500000007121865subscriptions_y2016_m120704718243768384vacuum_multixact_freeze_min_age500000050000007121865subscriptions_y2016_m120704718243768384vacuum_multixact_freeze_table_age150000000150000000

5. autovacuum_vacuum_cost_delay = 1ms

...

Рейтинг:

0 / 0

17.03.2016, 12:54

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194307

vyegorov

Участник

Откуда: Баньоло-ин-Пьяно

Сообщения: 1 237

Рейтинг: 0 / 0

VerusKpgsql.sess.totalpgsql.sess.idlepgsql.sess.idlexidpgsql.sess.activepgsql.sess.waitingpgsql.sess.age[15s]pgsql.sess.age[60s]pgsql.sess.age[300s]pgsql.sess.age[600s]pgsql.sess.age[1800s]pgsql.sess.age[3600s]pgsql.sess.age[max]38133624211122141934146
2 сессии `idle in transaction` — это зачем и почему?
1 сессия ждёт чего-то — чего?

Рабочих сессий 42, простаивают 336, из них дольше часа — 146. Может их надо проверить и отключить?

...

Рейтинг:

0 / 0

17.03.2016, 13:09

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194320

qwwq

Участник

Сообщения: 2 880

Рейтинг: 0 / 0

vyegorov,

я конечно дико извиняюсь, но за

Код: sql

1.
2.
3.

       count(CASE WHEN age(now(), backend_start) BETWEEN '0' AND '15s' THEN 1 END)       "pgsql.sess.age[15s]",
       count(CASE WHEN age(now(), backend_start) BETWEEN '16s' AND '60s' THEN 1 END)     "pgsql.sess.age[60s]",

-- руки из жопы надо выдирать с корнем.

или квантуйте хотя бы секундами:

Код: sql

age(now(), backend_start)::interval(0)

,
или пользуйтесь полуоткрытыми интервалами (что предпочтительней).

...

Рейтинг:

0 / 0

17.03.2016, 13:22

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194329

VerusK

Гость

vyegorov,

idle in transaction - запросы от приложения, отрабатывают быстро
сессия в ожидании то появляется, то исчезает, тоже отрабатывает быстро

...

Рейтинг:

0 / 0

17.03.2016, 13:27

| Ответить | Цитировать | Написать

Очень долгий autovacuum (to prevent wraparound)

#39194332

vyegorov

Участник

Откуда: Баньоло-ин-Пьяно

Сообщения: 1 237

Рейтинг: 0 / 0

qwwq,

А поделитесь правильным вариантом этого запроса, который бы работал на версиях начиная с 9.0?

...

Рейтинг:

0 / 0

17.03.2016, 13:28

| Ответить | Цитировать | Написать

25 сообщений из 104, страница 3 из 5

все

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Очень долгий autovacuum (to prevent wraparound)

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=53&msg=39192989&tid=1997327]:	0ms
get settings:	6ms
get forum list:	10ms
check forum access:	2ms
check topic access:	2ms
track hit:	33ms
get topic data:	7ms
get forum data:	2ms
get page messages:	41ms
get tp. blocked users:	1ms
others:	213ms

total:	317ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы