ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Очень долгий autovacuum (to prevent wraparound)
104 сообщений из 104, показаны все 5 страниц
  все  
Очень долгий autovacuum (to prevent wraparound)
    #39191429
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Прикладываю скрин текущего состояния. Заняты все воркеры для автовакуума - https://www.dropbox.com/s/wnm395rd2uigjal/Screenshot 2016-03-14 14.45.24.png?dl=0

Еще проблема в том, что как только заканчивается автовакуум по таблице, тут же начинается новый на эту же таблицу. Ранше такого не было никогда, хотя размер БД менятся +- 50Гб каждый месяц. Что-то добавляется, что-то удаляется(удаляются в основном таблицы целиком, не записи). Выглядит все очень странно и пугающе.
Если это важно, то на сервере настроена стандартная потоковая репликация + репликация Slony
...
Рейтинг: 0 / 0
14.03.2016, 14:50
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191434
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Еще доп инфо:
SELECT datname, age(datfrozenxid) FROM pg_database;

Код: plsql
1.
2.
3.
4.
5.
template1	377020598
template0	377020598
postgres	361825502
ho2_slave	361825502
ho2	        411825502



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



select * from pg_prepared_xacts; - ничего не возвращает
...
Рейтинг: 0 / 0
14.03.2016, 14:55
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191466
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

Какие настройки правили недавно?..

Что говорит:
Код: sql
1.
SELECT name,setting,unit FROM pg_settings WHERE source NOT IN ('default','override');
...
Рейтинг: 0 / 0
14.03.2016, 15:15
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191471
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Код: 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.
autovacuum	on	
autovacuum_analyze_scale_factor	0.005	
autovacuum_max_workers	20	
autovacuum_vacuum_scale_factor	0.01	
bgwriter_delay	200	ms
checkpoint_completion_target	0.9	
checkpoint_segments	128	
checkpoint_timeout	1800	s
client_encoding	UTF8	
client_min_messages	debug1	
commit_delay	5000	
commit_siblings	15	
DateStyle	ISO, MDY	
deadlock_timeout	1000	ms
debug_pretty_print	on	
default_statistics_target	100	
default_text_search_config	pg_catalog.english	
dynamic_shared_memory_type	posix	
effective_cache_size	12582912	8kB
extra_float_digits	3	
fsync	on	
full_page_writes	off	
lc_messages	en_US.UTF-8	
lc_monetary	en_US.UTF-8	
lc_numeric	en_US.UTF-8	
lc_time	en_US.UTF-8	
listen_addresses	*	
log_checkpoints	on	
log_destination	stderr	
log_directory	/home/pgsql/data/pg_log	
log_filename	postgresql-%a.log	
log_line_prefix	%t %h %u %p 	
log_lock_waits	on	
log_min_duration_statement	1000	ms
log_min_error_statement	debug1	
log_min_messages	debug1	
log_rotation_age	1440	min
log_rotation_size	0	kB
log_statement	none	
log_timezone	UTC	
log_truncate_on_rotation	on	
logging_collector	on	
maintenance_work_mem	2097152	kB
max_connections	800	
max_prepared_transactions	10	
max_replication_slots	3	
max_stack_depth	2048	kB
max_wal_senders	3	
port	9125	
random_page_cost	1.2	
search_path	public	
seq_page_cost	1	
shared_buffers	6553600	8kB
synchronous_commit	off	
temp_buffers	16384	8kB
TimeZone	Europe/Moscow	
track_counts	on	
update_process_title	off	
vacuum_cost_delay	5	ms
wal_buffers	2048	8kB
wal_keep_segments	128	
wal_level	hot_standby	
work_mem	65536	kB
...
Рейтинг: 0 / 0
14.03.2016, 15:20
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191533
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

вывод в предыдущем сообщении
...
Рейтинг: 0 / 0
14.03.2016, 16:13
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191538
Author the new one
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Author the new one
Участник
VerusK,

Я правильно понимаю, что у вас довольно много таблиц read only?
...
Рейтинг: 0 / 0
14.03.2016, 16:16
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191585
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

добавьте тосты в вывод
например

Код: sql
1.
SELECT relname, age(relfrozenxid) FROM pg_class WHERE relkind in ( 'r','t') order by age(relfrozenxid) desc;


или поджойнитесь табличкой на тосты. возьмите greatest.

и добавьте pg_table_size(oid::regclass) [если age начнут расходиться]. -- посмотреть как оно по возрасту скучковалось.
...
Рейтинг: 0 / 0
14.03.2016, 17:06
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191666
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

вывод на
Код: plsql
1.
SELECT relname, age(relfrozenxid), pg_table_size(oid::regclass) FROM pg_class WHERE relkind in ( 'r','t') 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.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.
298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
308.
309.
310.
311.
312.
313.
314.
315.
316.
317.
318.
319.
320.
321.
322.
323.
324.
325.
326.
327.
328.
329.
330.
331.
332.
333.
334.
335.
336.
337.
338.
339.
340.
341.
subscriptions_y2016_m1	418599664	169881706496
pg_type	368599664	409600
pg_toast_19619	368599664	0
pg_toast_2619	368599664	80216064
pg_toast_1255	368599664	40960
pg_toast_2604	368599664	0
pg_toast_2606	368599664	0
pg_toast_2618	368599664	417792
pg_toast_2620	368599664	0
pg_toast_2609	368599664	0
pg_toast_2964	368599664	0
pg_toast_2396	368599664	0
pg_toast_3596	368599664	0
pg_toast_19625	368599664	0
pg_authid	368599664	40960
pg_attribute	368599664	5406720
pg_proc	368599664	811008
pg_toast_19633	368599664	0
pg_user_mapping	368599664	0
pg_attrdef	368599664	147456
pg_constraint	368599664	827392
pg_index	368599664	1286144
pg_operator	368599664	155648
pg_opfamily	368599664	49152
pg_opclass	368599664	57344
pg_am	368599664	40960
pg_amop	368599664	65536
pg_amproc	368599664	57344
pg_language	368599664	40960
pg_toast_5367021	368599664	0
pg_aggregate	368599664	49152
pg_rewrite	368599664	557056
pg_trigger	368599664	81920
pg_event_trigger	368599664	0
pg_description	368599664	344064
pg_cast	368599664	49152
pg_enum	368599664	0
pg_namespace	368599664	65536
pg_conversion	368599664	57344
pg_depend	368599664	1310720
pg_database	368599664	40960
pg_db_role_setting	368599664	8192
pg_tablespace	368599664	40960
pg_pltemplate	368599664	40960
pg_auth_members	368599664	0
pg_shdepend	368599664	106496
pg_shdescription	368599664	49152
pg_ts_config	368599664	40960
pg_ts_config_map	368599664	49152
pg_ts_dict	368599664	40960
pg_ts_parser	368599664	40960
pg_ts_template	368599664	40960
pg_extension	368599664	40960
pg_foreign_data_wrapper	368599664	0
pg_foreign_server	368599664	0
pg_foreign_table	368599664	0
pg_default_acl	368599664	0
pg_seclabel	368599664	8192
pg_shseclabel	368599664	0
pg_collation	368599664	114688
pg_range	368599664	40960
pg_largeobject	368599664	0
pg_toast_19641	368599664	0
sql_implementation_info	368599664	49152
pg_toast_12029	368599664	0
sql_languages	368599664	49152
pg_toast_12034	368599664	0
sql_packages	368599664	49152
pg_toast_12039	368599664	0
pg_toast_12044	368599664	0
sql_sizing	368599664	49152
sql_sizing_profiles	368599664	8192
pg_toast_12054	368599664	0
pg_class	368599664	1359872
cb_settings	368599664	0
pg_toast_19660	368599664	0
pg_largeobject_metadata	368599664	0
pg_toast_19673	368599664	0
pg_inherits	368599664	65536
pg_toast_19883	368599664	0
pg_toast_19681	368599664	0
pg_toast_12024	368599664	0
sql_features	368599664	98304
sql_parts	368599664	49152
pg_toast_12049	368599664	0
pg_toast_11447306	368599664	1420574720
pg_toast_19710	368599664	0
pg_toast_19718	368599664	0
pg_toast_1822692	368599664	90112
inner_logs_y2016_m3	368599664	2620555264
pg_toast_1427785	368599664	0
pg_toast_7121865	368599664	221184000
pg_toast_19767	368599664	0
login_history	368599664	2154496
netspeed	368599664	0
pg_toast_19781	368599664	0
pg_toast_19789	368599664	0
pg_toast_1737041	368599664	9535488
pg_toast_1822703	368599664	0
pg_toast_1220340	368599664	0
pg_toast_19866	368599664	0
pg_toast_19850	368599664	0
pg_toast_19858	368599664	0
pg_toast_19891	368599664	0
pg_toast_19899	368599664	0
pg_toast_1913201	368599664	40960
pg_toast_19773	368599664	131072
pg_toast_2663889	368599664	0
pg_toast_8824233	368599664	0
pg_toast_8824244	368599664	0
pg_toast_7121876	368599664	0
clicks	368599664	8192
pg_toast_9797702	368599664	0
pg_toast_9328942	368599664	214638592
subscriptions_y2016_m2	368599664	136129110016
stats_y2016_m1	368599664	24576
error_statistics	368599664	1510285312
stats_referral	368599664	90112
stats_y2016_m2	368599664	13444325376
pg_toast_9328953	368599664	0
pg_toast_20025	368599664	0
geo_indexes	368599664	14614528
pg_toast_20033	368599664	0
pg_toast_1491171	368599664	4120576
pg_toast_1609808	368599664	0
pg_toast_20182	368599664	1105920
pg_toast_1251468	368599664	49152
translations	368599664	147456
pg_toast_20198	368599664	40960
pg_toast_20165	368599664	0
pg_toast_20173	368599664	0
pg_toast_7121900	368599664	6891618304
pg_toast_1334580	368599664	0
pg_toast_20190	368599664	0
rebills	368599664	8192
logs_y2016_m1	368599664	12130820096
conversion_funnel	368599664	8192
pg_toast_4758518	368599664	966656
pg_toast_10387547	368599664	0
pg_toast_9328984	368599664	6531874816
logs_y2016_m2	368599664	12653543424
pg_toast_11447631	368599664	68157440
pg_toast_2377387	368599664	0
leads_y2015_m12	368599664	112680960
pg_toast_7121915	368599664	2719744
inner_logs_y2016_m1	368599664	66404352
pg_toast_19797	368599664	0
orders_y2015_m4	368599664	87744512
pg_toast_7121943	368599664	573440
leads_y2016_m1	368599664	152657920
success_pages	368599664	8192
pg_toast_19759	368599664	0
pg_toast_771870	368599664	3399680
leads_y2016_m3	368599664	1369513984
pg_toast_9328999	368599664	79519744
orders_y2015_m7	368599664	134799360
orders_y2016_m2	368599664	667385856
pg_toast_7121980	368599664	34299904
stats_y2015_m12	368599664	24576
orders_y2016_m1	368599664	554377216
pg_toast_9329074	368599664	15663104
pg_toast_4758564	368599664	0
leads_y2016_m2	368599664	276488192
pg_toast_9329126	368599664	3129344
inner_logs_y2016_m2	368599664	63774720
pg_toast_3767161	368599664	0
pg_toast_1575647	368599664	0
transactions	368599664	66240512
withdrawal_accounts	368599664	8192
pg_toast_1482461	368599664	376832
pg_toast_11447101	368599664	227721216
subscriptions_y2016_m3	368599664	77406429184
orders_y2015_m9	368599664	460341248
orders_y2015_m10	368599664	5374738432
stats_y2016_m3	368599664	14815297536
pg_toast_2210994	368599664	11821056
pg_toast_3767172	368599664	0
pg_toast_11447112	368599664	0
orders_y2015_m12	368599664	7492591616
accounts	368599664	8192
pg_toast_9632750	368599664	0
offers_trafficback	368599664	57344
pg_toast_4759413	368599664	62758912
pg_toast_5372727	368599664	0
conversion_funnel_y2015_m12	368599664	1283481600
orders_y2015_m8	368599664	159645696
orders_y2015_m5	368599664	113352704
inner_logs	368599664	8192
pg_toast_306722	368599664	0
pg_toast_19652	368599664	0
orders_y2015_m3	368599664	85237760
orders_y2015_m1	368599664	8675328
redress_history	368599664	73728
pg_toast_997998	368599664	0
submit_errors	368599664	974848
pg_toast_1103290	368599664	0
pg_toast_20149	368599664	0
ticket_answers	368599664	172032
pg_toast_19738	368599664	704512
authtokens	368599664	65536
countries_ranges	368599664	0
bp_service_codes	368599664	8192
categories	368599664	49152
browsers	368599664	229376
logs	368599664	49152
comebackers	368599664	57344
postback_urls	368599664	712704
currencies	368599664	49152
rates_modifiers	368599664	8192
subscriptions	368599664	8192
currencies_rates	368599664	851968
offer_targeting	368599664	3219456
subaccounts	368599664	8192
tickets	368599664	57344
stats	368599664	8192
offer_settings	368599664	1032192
orders_y2014_m12	368599664	884736
orders_y2015_m2	368599664	50962432
offers	368599664	25313280
pg_statistic	368599664	129744896
pg_toast_19689	368599664	0
pg_toast_918243	368599664	0
pg_toast_3767183	368599664	0
pg_toast_635480	368599664	0
pg_toast_635506	368599664	0
pg_toast_635531	368599664	1212416
pg_toast_634483	368599664	2080768
transaction_requests	368599664	884736
orders	368599664	8192
pg_toast_659171	368599664	1662976
pg_toast_959631	368599664	5808128
pg_toast_11447137	368599664	3274604544
logs_y2016_m3	368599664	5882339328
pg_toast_19923	368599664	0
pg_toast_1259747	368599664	4874240
pg_toast_11447152	368599664	91398144
orders_y2016_m3	368599664	1541439488
action_flows	368599664	49152
logs_y2015_m9	368599664	2086158336
pg_toast_1736799	368599664	836567040
advertiser_requests	368599664	106496
blacklist	368599664	57344
blog_categories	368599664	49152
blog_posts	368599664	155648
news	368599664	892928
notifications	368599664	1613824
orders_y2015_m11	368599664	12357763072
pg_toast_1736814	368599664	58916864
inner_logs_y2015_m9	368599664	573349888
pg_toast_3058402	368599664	51314688
pg_toast_3767195	368599664	0
promo	368599664	147456
mailing_lists	368599664	458752
caps	368599664	3571712
conversion_types	368599664	40960
countries	368599664	98304
domains	368599664	163840
goods	368599664	40960
ip_geo_base	368599664	17956864
pg_toast_19697	368599664	0
ip_ranges	368599664	360448
offer_weights	368599664	8192
operating_systems	368599664	163840
operators	368599664	49152
organizations	368599664	8192
platforms	368599664	1179648
platforms_urls	368599664	368640
prelandings_settings	368599664	778240
rotators	368599664	819200
settings	368599664	8192
traffic_managers	368599664	49152
traffic_redirect	368599664	49152
traffic_sources	368599664	40960
user_settings	368599664	188416
user_types	368599664	65536
users	368599664	18669568
leads	368599664	8192
pg_toast_1350990	368599664	0
leads_y2014_m12	368599664	122880
pg_toast_1351002	368599664	0
leads_y2015_m1	368599664	335872
pg_toast_1351030	368599664	0
leads_y2015_m2	368599664	589824
groups	368599664	49152
pg_toast_1351058	368599664	0
leads_y2015_m3	368599664	589824
pg_toast_1351087	368599664	0
leads_y2015_m4	368599664	540672
pg_toast_1351116	368599664	0
pg_toast_19874	368599664	0
leads_y2015_m5	368599664	1368064
pg_toast_1351182	368599664	0
leads_y2015_m6	368599664	565248
pg_toast_1351259	368599664	0
leads_y2015_m7	368599664	16261120
pg_toast_1351289	368599664	49152
leads_y2015_m8	368599664	85368832
pg_toast_1491170	368599664	73728
leads_y2015_m9	368599664	133095424
pg_toast_1736973	368599664	1114112
leads_y2015_m10	368599664	143294464
pg_toast_2210948	368599664	409600
leads_y2015_m11	368599664	129449984
pg_toast_3058475	368599664	466944
pg_toast_20157	368599664	0
orders_y2015_m6	368599664	126271488
pg_toast_231562	368599664	0
prelandings	368599664	671744
sl_sequence	200619060	8192
sl_nodelock	200619060	8192
pg_toast_12132135	200619060	0
pg_toast_12132166	200619060	0
sl_table	200619060	16384
pg_toast_12132181	200619060	0
pg_toast_12132119	200619060	0
pg_toast_12132196	200619060	0
sl_event_lock	200619060	0
pg_toast_12132148	200619060	0
sl_archive_counter	200619060	8192
sl_node	200619060	16384
sl_listen	200619060	8192
pg_toast_12132322	200619060	0
sl_components	200619060	46694400
sl_path	200619060	16384
sl_set	200619060	16384
sl_subscribe	200619060	8192
pg_toast_12132244	200619060	0
sl_event	200619060	9658368
sl_confirm	200619060	4268032
sl_seqlog	200619060	0
pg_toast_12132277	200619060	0
sl_log_script	200619060	8192
pg_toast_12132284	200619060	0
sl_registry	200619060	65536
sl_apply_stats	200619060	6332416
sl_setsync	200619060	8192
sl_config_lock	200619060	0
pg_toast_12132270	1563186	0
sl_log_2	1563186	73728
sl_log_1	721603	81920
pg_toast_12132263	721603	0



не совсем понял

Author the new one, чисто read only таблиц нет, достаточно много из которых больше читают чем пишут, конечно.
...
Рейтинг: 0 / 0
14.03.2016, 18:28
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191684
Author the new one
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Author the new one
Участник
VerusK,

А вот по скриншоту у вас видно таблицы orders_y2015_m05 и т.п. Это что же, туда до сих пор пишут?

Вообще в настоящий момент постгрес должен периодически перетряхивать таблицы на предмет предотвращения wraparound-а, даже если там ничего не менялось. Можете попробовать выделить такие неменяющиеся таблицы, запретить на них модификацию, прогнать
vacuum full и выключить на них автовакуум.
...
Рейтинг: 0 / 0
14.03.2016, 18:46
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191685
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Author the new one,

а что делать с текущими запущенными автовакуумами? Они до сих пор работают как на первом скрине и не думают останавливаться. Есть даже запущенные на пустые таблицы. Это вообще странно.
...
Рейтинг: 0 / 0
14.03.2016, 18:48
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191686
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Author the new one,

вы не понимаете природы прокрутки белки в колесе.
даже если белка старая и не меняется, колесо всё равно крутится.
а механизм меток, позволяющий не крутится архивным белкам , будет закоммичен только в 9.6. (карта метки блоков полностью "в прошлом")
...
Рейтинг: 0 / 0
14.03.2016, 18:50
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191691
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

Поэтому и пришел за помощью. Не понятно, что делать в текущей ситуации. Автовакуум после авршения начинается по кругу, причем опять "to prevent wraparound" на те же таблицы.
...
Рейтинг: 0 / 0
14.03.2016, 18:54
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191692
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK, у вас создан довольно большой "бунч" для достаточно маленькой бд

вот я вам его показываю:

 
Код: 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.
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.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.
298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
308.
309.
310.
311.
312.
313.
314.
315.
316.
317.
318.
319.
320.
321.
322.
323.
324.
325.
326.
327.
328.
329.
330.
331.
332.
333.
334.
335.
336.
337.
338.
339.
340.
341.
342.
343.
344.
345.
346.
347.
348.
349.
WITH ages (name,age,size) AS (values
('subscriptions_y2016_m1',bigint'418599664',bigint'169881706496')
,('pg_type','368599664','409600')
,('pg_toast_19619','368599664','0')
,('pg_toast_2619','368599664','80216064')
,('pg_toast_1255','368599664','40960')
,('pg_toast_2604','368599664','0')
,('pg_toast_2606','368599664','0')
,('pg_toast_2618','368599664','417792')
,('pg_toast_2620','368599664','0')
,('pg_toast_2609','368599664','0')
,('pg_toast_2964','368599664','0')
,('pg_toast_2396','368599664','0')
,('pg_toast_3596','368599664','0')
,('pg_toast_19625','368599664','0')
,('pg_authid','368599664','40960')
,('pg_attribute','368599664','5406720')
,('pg_proc','368599664','811008')
,('pg_toast_19633','368599664','0')
,('pg_user_mapping','368599664','0')
,('pg_attrdef','368599664','147456')
,('pg_constraint','368599664','827392')
,('pg_index','368599664','1286144')
,('pg_operator','368599664','155648')
,('pg_opfamily','368599664','49152')
,('pg_opclass','368599664','57344')
,('pg_am','368599664','40960')
,('pg_amop','368599664','65536')
,('pg_amproc','368599664','57344')
,('pg_language','368599664','40960')
,('pg_toast_5367021','368599664','0')
,('pg_aggregate','368599664','49152')
,('pg_rewrite','368599664','557056')
,('pg_trigger','368599664','81920')
,('pg_event_trigger','368599664','0')
,('pg_description','368599664','344064')
,('pg_cast','368599664','49152')
,('pg_enum','368599664','0')
,('pg_namespace','368599664','65536')
,('pg_conversion','368599664','57344')
,('pg_depend','368599664','1310720')
,('pg_database','368599664','40960')
,('pg_db_role_setting','368599664','8192')
,('pg_tablespace','368599664','40960')
,('pg_pltemplate','368599664','40960')
,('pg_auth_members','368599664','0')
,('pg_shdepend','368599664','106496')
,('pg_shdescription','368599664','49152')
,('pg_ts_config','368599664','40960')
,('pg_ts_config_map','368599664','49152')
,('pg_ts_dict','368599664','40960')
,('pg_ts_parser','368599664','40960')
,('pg_ts_template','368599664','40960')
,('pg_extension','368599664','40960')
,('pg_foreign_data_wrapper','368599664','0')
,('pg_foreign_server','368599664','0')
,('pg_foreign_table','368599664','0')
,('pg_default_acl','368599664','0')
,('pg_seclabel','368599664','8192')
,('pg_shseclabel','368599664','0')
,('pg_collation','368599664','114688')
,('pg_range','368599664','40960')
,('pg_largeobject','368599664','0')
,('pg_toast_19641','368599664','0')
,('sql_implementation_info','368599664','49152')
,('pg_toast_12029','368599664','0')
,('sql_languages','368599664','49152')
,('pg_toast_12034','368599664','0')
,('sql_packages','368599664','49152')
,('pg_toast_12039','368599664','0')
,('pg_toast_12044','368599664','0')
,('sql_sizing','368599664','49152')
,('sql_sizing_profiles','368599664','8192')
,('pg_toast_12054','368599664','0')
,('pg_class','368599664','1359872')
,('cb_settings','368599664','0')
,('pg_toast_19660','368599664','0')
,('pg_largeobject_metadata','368599664','0')
,('pg_toast_19673','368599664','0')
,('pg_inherits','368599664','65536')
,('pg_toast_19883','368599664','0')
,('pg_toast_19681','368599664','0')
,('pg_toast_12024','368599664','0')
,('sql_features','368599664','98304')
,('sql_parts','368599664','49152')
,('pg_toast_12049','368599664','0')
,('pg_toast_11447306','368599664','1420574720')
,('pg_toast_19710','368599664','0')
,('pg_toast_19718','368599664','0')
,('pg_toast_1822692','368599664','90112')
,('inner_logs_y2016_m3','368599664','2620555264')
,('pg_toast_1427785','368599664','0')
,('pg_toast_7121865','368599664','221184000')
,('pg_toast_19767','368599664','0')
,('login_history','368599664','2154496')
,('netspeed','368599664','0')
,('pg_toast_19781','368599664','0')
,('pg_toast_19789','368599664','0')
,('pg_toast_1737041','368599664','9535488')
,('pg_toast_1822703','368599664','0')
,('pg_toast_1220340','368599664','0')
,('pg_toast_19866','368599664','0')
,('pg_toast_19850','368599664','0')
,('pg_toast_19858','368599664','0')
,('pg_toast_19891','368599664','0')
,('pg_toast_19899','368599664','0')
,('pg_toast_1913201','368599664','40960')
,('pg_toast_19773','368599664','131072')
,('pg_toast_2663889','368599664','0')
,('pg_toast_8824233','368599664','0')
,('pg_toast_8824244','368599664','0')
,('pg_toast_7121876','368599664','0')
,('clicks','368599664','8192')
,('pg_toast_9797702','368599664','0')
,('pg_toast_9328942','368599664','214638592')
,('subscriptions_y2016_m2','368599664','136129110016')
,('stats_y2016_m1','368599664','24576')
,('error_statistics','368599664','1510285312')
,('stats_referral','368599664','90112')
,('stats_y2016_m2','368599664','13444325376')
,('pg_toast_9328953','368599664','0')
,('pg_toast_20025','368599664','0')
,('geo_indexes','368599664','14614528')
,('pg_toast_20033','368599664','0')
,('pg_toast_1491171','368599664','4120576')
,('pg_toast_1609808','368599664','0')
,('pg_toast_20182','368599664','1105920')
,('pg_toast_1251468','368599664','49152')
,('translations','368599664','147456')
,('pg_toast_20198','368599664','40960')
,('pg_toast_20165','368599664','0')
,('pg_toast_20173','368599664','0')
,('pg_toast_7121900','368599664','6891618304')
,('pg_toast_1334580','368599664','0')
,('pg_toast_20190','368599664','0')
,('rebills','368599664','8192')
,('logs_y2016_m1','368599664','12130820096')
,('conversion_funnel','368599664','8192')
,('pg_toast_4758518','368599664','966656')
,('pg_toast_10387547','368599664','0')
,('pg_toast_9328984','368599664','6531874816')
,('logs_y2016_m2','368599664','12653543424')
,('pg_toast_11447631','368599664','68157440')
,('pg_toast_2377387','368599664','0')
,('leads_y2015_m12','368599664','112680960')
,('pg_toast_7121915','368599664','2719744')
,('inner_logs_y2016_m1','368599664','66404352')
,('pg_toast_19797','368599664','0')
,('orders_y2015_m4','368599664','87744512')
,('pg_toast_7121943','368599664','573440')
,('leads_y2016_m1','368599664','152657920')
,('success_pages','368599664','8192')
,('pg_toast_19759','368599664','0')
,('pg_toast_771870','368599664','3399680')
,('leads_y2016_m3','368599664','1369513984')
,('pg_toast_9328999','368599664','79519744')
,('orders_y2015_m7','368599664','134799360')
,('orders_y2016_m2','368599664','667385856')
,('pg_toast_7121980','368599664','34299904')
,('stats_y2015_m12','368599664','24576')
,('orders_y2016_m1','368599664','554377216')
,('pg_toast_9329074','368599664','15663104')
,('pg_toast_4758564','368599664','0')
,('leads_y2016_m2','368599664','276488192')
,('pg_toast_9329126','368599664','3129344')
,('inner_logs_y2016_m2','368599664','63774720')
,('pg_toast_3767161','368599664','0')
,('pg_toast_1575647','368599664','0')
,('transactions','368599664','66240512')
,('withdrawal_accounts','368599664','8192')
,('pg_toast_1482461','368599664','376832')
,('pg_toast_11447101','368599664','227721216')
,('subscriptions_y2016_m3','368599664','77406429184')
,('orders_y2015_m9','368599664','460341248')
,('orders_y2015_m10','368599664','5374738432')
,('stats_y2016_m3','368599664','14815297536')
,('pg_toast_2210994','368599664','11821056')
,('pg_toast_3767172','368599664','0')
,('pg_toast_11447112','368599664','0')
,('orders_y2015_m12','368599664','7492591616')
,('accounts','368599664','8192')
,('pg_toast_9632750','368599664','0')
,('offers_trafficback','368599664','57344')
,('pg_toast_4759413','368599664','62758912')
,('pg_toast_5372727','368599664','0')
,('conversion_funnel_y2015_m12','368599664','1283481600')
,('orders_y2015_m8','368599664','159645696')
,('orders_y2015_m5','368599664','113352704')
,('inner_logs','368599664','8192')
,('pg_toast_306722','368599664','0')
,('pg_toast_19652','368599664','0')
,('orders_y2015_m3','368599664','85237760')
,('orders_y2015_m1','368599664','8675328')
,('redress_history','368599664','73728')
,('pg_toast_997998','368599664','0')
,('submit_errors','368599664','974848')
,('pg_toast_1103290','368599664','0')
,('pg_toast_20149','368599664','0')
,('ticket_answers','368599664','172032')
,('pg_toast_19738','368599664','704512')
,('authtokens','368599664','65536')
,('countries_ranges','368599664','0')
,('bp_service_codes','368599664','8192')
,('categories','368599664','49152')
,('browsers','368599664','229376')
,('logs','368599664','49152')
,('comebackers','368599664','57344')
,('postback_urls','368599664','712704')
,('currencies','368599664','49152')
,('rates_modifiers','368599664','8192')
,('subscriptions','368599664','8192')
,('currencies_rates','368599664','851968')
,('offer_targeting','368599664','3219456')
,('subaccounts','368599664','8192')
,('tickets','368599664','57344')
,('stats','368599664','8192')
,('offer_settings','368599664','1032192')
,('orders_y2014_m12','368599664','884736')
,('orders_y2015_m2','368599664','50962432')
,('offers','368599664','25313280')
,('pg_statistic','368599664','129744896')
,('pg_toast_19689','368599664','0')
,('pg_toast_918243','368599664','0')
,('pg_toast_3767183','368599664','0')
,('pg_toast_635480','368599664','0')
,('pg_toast_635506','368599664','0')
,('pg_toast_635531','368599664','1212416')
,('pg_toast_634483','368599664','2080768')
,('transaction_requests','368599664','884736')
,('orders','368599664','8192')
,('pg_toast_659171','368599664','1662976')
,('pg_toast_959631','368599664','5808128')
,('pg_toast_11447137','368599664','3274604544')
,('logs_y2016_m3','368599664','5882339328')
,('pg_toast_19923','368599664','0')
,('pg_toast_1259747','368599664','4874240')
,('pg_toast_11447152','368599664','91398144')
,('orders_y2016_m3','368599664','1541439488')
,('action_flows','368599664','49152')
,('logs_y2015_m9','368599664','2086158336')
,('pg_toast_1736799','368599664','836567040')
,('advertiser_requests','368599664','106496')
,('blacklist','368599664','57344')
,('blog_categories','368599664','49152')
,('blog_posts','368599664','155648')
,('news','368599664','892928')
,('notifications','368599664','1613824')
,('orders_y2015_m11','368599664','12357763072')
,('pg_toast_1736814','368599664','58916864')
,('inner_logs_y2015_m9','368599664','573349888')
,('pg_toast_3058402','368599664','51314688')
,('pg_toast_3767195','368599664','0')
,('promo','368599664','147456')
,('mailing_lists','368599664','458752')
,('caps','368599664','3571712')
,('conversion_types','368599664','40960')
,('countries','368599664','98304')
,('domains','368599664','163840')
,('goods','368599664','40960')
,('ip_geo_base','368599664','17956864')
,('pg_toast_19697','368599664','0')
,('ip_ranges','368599664','360448')
,('offer_weights','368599664','8192')
,('operating_systems','368599664','163840')
,('operators','368599664','49152')
,('organizations','368599664','8192')
,('platforms','368599664','1179648')
,('platforms_urls','368599664','368640')
,('prelandings_settings','368599664','778240')
,('rotators','368599664','819200')
,('settings','368599664','8192')
,('traffic_managers','368599664','49152')
,('traffic_redirect','368599664','49152')
,('traffic_sources','368599664','40960')
,('user_settings','368599664','188416')
,('user_types','368599664','65536')
,('users','368599664','18669568')
,('leads','368599664','8192')
,('pg_toast_1350990','368599664','0')
,('leads_y2014_m12','368599664','122880')
,('pg_toast_1351002','368599664','0')
,('leads_y2015_m1','368599664','335872')
,('pg_toast_1351030','368599664','0')
,('leads_y2015_m2','368599664','589824')
,('groups','368599664','49152')
,('pg_toast_1351058','368599664','0')
,('leads_y2015_m3','368599664','589824')
,('pg_toast_1351087','368599664','0')
,('leads_y2015_m4','368599664','540672')
,('pg_toast_1351116','368599664','0')
,('pg_toast_19874','368599664','0')
,('leads_y2015_m5','368599664','1368064')
,('pg_toast_1351182','368599664','0')
,('leads_y2015_m6','368599664','565248')
,('pg_toast_1351259','368599664','0')
,('leads_y2015_m7','368599664','16261120')
,('pg_toast_1351289','368599664','49152')
,('leads_y2015_m8','368599664','85368832')
,('pg_toast_1491170','368599664','73728')
,('leads_y2015_m9','368599664','133095424')
,('pg_toast_1736973','368599664','1114112')
,('leads_y2015_m10','368599664','143294464')
,('pg_toast_2210948','368599664','409600')
,('leads_y2015_m11','368599664','129449984')
,('pg_toast_3058475','368599664','466944')
,('pg_toast_20157','368599664','0')
,('orders_y2015_m6','368599664','126271488')
,('pg_toast_231562','368599664','0')
,('prelandings','368599664','671744')
,('sl_sequence','200619060','8192')
,('sl_nodelock','200619060','8192')
,('pg_toast_12132135','200619060','0')
,('pg_toast_12132166','200619060','0')
,('sl_table','200619060','16384')
,('pg_toast_12132181','200619060','0')
,('pg_toast_12132119','200619060','0')
,('pg_toast_12132196','200619060','0')
,('sl_event_lock','200619060','0')
,('pg_toast_12132148','200619060','0')
,('sl_archive_counter','200619060','8192')
,('sl_node','200619060','16384')
,('sl_listen','200619060','8192')
,('pg_toast_12132322','200619060','0')
,('sl_components','200619060','46694400')
,('sl_path','200619060','16384')
,('sl_set','200619060','16384')
,('sl_subscribe','200619060','8192')
,('pg_toast_12132244','200619060','0')
,('sl_event','200619060','9658368')
,('sl_confirm','200619060','4268032')
,('sl_seqlog','200619060','0')
,('pg_toast_12132277','200619060','0')
,('sl_log_script','200619060','8192')
,('pg_toast_12132284','200619060','0')
,('sl_registry','200619060','65536')
,('sl_apply_stats','200619060','6332416')
,('sl_setsync','200619060','8192')
,('sl_config_lock','200619060','0')
,('pg_toast_12132270','1563186','0')
,('sl_log_2','1563186','73728')
,('sl_log_1','721603','81920')
,('pg_toast_12132263','721603','0')
)
SELECT age
	,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



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

из штатных механизмов такой штуки -- подозреваю что то про оочень длинные висячие транзакции, мешающие зафройзить моментом старта фриза.
...
Рейтинг: 0 / 0
14.03.2016, 18:56
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191699
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

руками в системные не писал никто, я уверен на 99%. Единственное, что делали нового в БД - это подключили Slony.
...
Рейтинг: 0 / 0
14.03.2016, 19:03
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191704
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

ищите источник или следы длинной транзакции.

со слониками не возился, но у них вероятно есть стартовый снапшот--синхронизатор ? -- вот он то и м.б. таким источником. (старая незакрытая транзакция держит глубину фриза константной, если я правильно помню логику).
...
Рейтинг: 0 / 0
14.03.2016, 19:09
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39191712
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

да у слоника есть некая отправная точка - подписывание ноды, он в этот момент создает триггеры и, наверное что-то еще делает с БД. Не совсем понял, что такое длинная транзакция и уж тем более не понял как ее искать и что с ней делать как найду :(
...
Рейтинг: 0 / 0
14.03.2016, 19:20
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192000
Author the new one
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Author the new one
Участник
qwwq,

Ох, вообще-то я предлагаю, если взять за основу ваш яркий образ, вставить палки в некоторые беличьи колеса.
...
Рейтинг: 0 / 0
15.03.2016, 11:01
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192102
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Author the new oneqwwq,

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


другое дело, что каждую старую тушку достаточно фризить однажды за оборот.
...
Рейтинг: 0 / 0
15.03.2016, 12:07
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192109
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

Код: sql
1.
select * FROM pg_stat_activity WHERE state<>'idle'
...
Рейтинг: 0 / 0
15.03.2016, 12:08
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192137
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

https://www.dropbox.com/s/3cd7pfafhkurmrf/pg_activity.csv?dl=0
...
Рейтинг: 0 / 0
15.03.2016, 12:24
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192152
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

а нельзя не отсылать на разные говносайты ?

тут есть :
 
аbc123



хотя я там ничего интересного не увидел. [интересно всё кроме вакуумов] всё интересное уже кончилось. ждите, когда воркеры раскидают очередную пачку. -- смотрите, развалится кучка, или не очень.
...
Рейтинг: 0 / 0
15.03.2016, 12:33
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192185
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

там нет никаких повисших зарпосов, запросы все отрабатывают в данный момент без блоков
...
Рейтинг: 0 / 0
15.03.2016, 12:49
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192324
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
VerusK,

в логах базы нет интересных записей?
...
Рейтинг: 0 / 0
15.03.2016, 14:24
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192338
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

Ну сейчас надо просто ждать.

Если нагрузка мешает основной, то смотрите на %vacuum_cost параметры, ставьте задержку в 10-20ms. Нагрузка станет меньше, но и завершаться они позже.
...
Рейтинг: 0 / 0
15.03.2016, 14:30
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192421
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Alexius,

вот такое начало появляться:
Код: plsql
1.
2.
2016-03-15 12:30:26 UTC   89175 WARNING:  oldest xmin is far in the past
2016-03-15 12:30:26 UTC   89175 HINT:  Close open transactions soon to avoid wraparound problems.



я так понимаю ничего хорошего это не означает :(
...
Рейтинг: 0 / 0
15.03.2016, 15:31
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192482
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

так у вас периодически висят длинные открытые транзакции кроме вакуумов, или не висят ?

вы уж как нить определитесь. мониторинг там, биту для любителей держать открытые клиентские транзакции сутками, прочее. простейший джоб отстрела висяков.
...
Рейтинг: 0 / 0
15.03.2016, 16:08
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192544
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

 
Смотрим сессии
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SELECT count(*)                                                  "pgsql.sess.total",
       count(CASE WHEN state = 'idle' THEN 1 END)                "pgsql.sess.idle",
       count(case WHEN state = 'idle in transaction' THEN 1 END) "pgsql.sess.idlexid",
       count(CASE WHEN NOT state ~~ 'idle%' AND NOT waiting THEN 1 END)        "pgsql.sess.active",
       count(CASE WHEN NOT state ~~ 'idle%' AND waiting THEN 1 END)            "pgsql.sess.waiting",
       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]",
       count(CASE WHEN age(now(), backend_start) BETWEEN '61s' AND '300s' THEN 1 END)    "pgsql.sess.age[300s]",
       count(CASE WHEN age(now(), backend_start) BETWEEN '301s' AND '600s' THEN 1 END)   "pgsql.sess.age[600s]",
       count(CASE WHEN age(now(), backend_start) BETWEEN '601s' AND '1800s' THEN 1 END)  "pgsql.sess.age[1800s]",
       count(CASE WHEN age(now(), backend_start) BETWEEN '1801s' AND '3600s' THEN 1 END) "pgsql.sess.age[3600s]",
       count(CASE WHEN age(now(), backend_start) > '3600s' THEN 1 END)                   "pgsql.sess.age[max]"
  FROM pg_stat_activity;


Всех `idle in transaction` — мочить. Всех дольше 5 минут и не активных — мочить.
...
Рейтинг: 0 / 0
15.03.2016, 16:55
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192603
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov, qwwq,

таких долгих транзакций конечно нет, запросы к БД идут, но все в штатном режиме. Где-то находил похожую проблему у человека висели prepared transactions
Код: plsql
1.
select * from  pg_prepared_xacts;


у меня такого нет.
...
Рейтинг: 0 / 0
15.03.2016, 17:52
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192614
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Я сейчас сделал
Код: plsql
1.
SELECT relname, age(relfrozenxid) FROM pg_class WHERE relkind = 'r' order by age(relfrozenxid) desc;



и age уже другой для таблиц.
...
Рейтинг: 0 / 0
15.03.2016, 18:15
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192626
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusKЯ сейчас сделал
Код: plsql
1.
SELECT relname, age(relfrozenxid) FROM pg_class WHERE relkind = 'r' order by age(relfrozenxid) desc;



и age уже другой для таблиц.сюрпайс, сюрпайс


я тут распинаюсь про беличье колесо, а до кого-то так и не доходит. замечательно приторможенные люди таки одмины. хехе
...
Рейтинг: 0 / 0
15.03.2016, 18:24
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192632
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

что это все значит? :)
...
Рейтинг: 0 / 0
15.03.2016, 18:31
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192638
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

age меняется каждый запрос
...
Рейтинг: 0 / 0
15.03.2016, 18:36
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192645
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusKqwwq,

age меняется каждый запросвозраст отсчитывается от текушего txid, а он меняется со скоростью потока пишущих транзакций. поэтому даже если фрозентксид стоит -- его возраст растёт.

там цилиндрическая координата txid. с несколькими выколотыми точками. например "2" -- всегда в абсолютном прошлом.

и вот всю эту кухню надо каждую эпоху проворачивать. хотя бы читать (если архивы).
...
Рейтинг: 0 / 0
15.03.2016, 18:44
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192649
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

автовакуумы приходят и уходят, такое ощущение, что он по всем таблицам проходится. Или так и должно быть? Я думал "эпоха" считается для каждой таблицы отдельно.
...
Рейтинг: 0 / 0
15.03.2016, 18:47
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192705
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusKавтовакуумы приходят и уходят, такое ощущение, что он по всем таблицам проходится. Или так и должно быть? Я думал "эпоха" считается для каждой таблицы отдельно.
автовакуум должен пройти по всем таблицам, у которых age() > autovacuum_freeze_max_age. которые из ваших попадают под условие легко проверить, как и то, сколько осталось.

да, эпоха считается для каждой отдельно. это просто разница между текущей транзакией (txid_current()) и самой старой из транзакций в таблице. естественно, если ничего не делать, то возраст будет расти, и чем больше пишущая активность, тем быстрее он растёт.
...
Рейтинг: 0 / 0
15.03.2016, 20:06
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192716
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

только что закончился вакуум нескольких таблиц, но у них age опять больше чем autovacuum_freeze_max_age (age(relfrozenxid) > 200000000), т.е. какой-то бесконечный цикл получается
...
Рейтинг: 0 / 0
15.03.2016, 20:17
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192728
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

Какая версия базы? У вас стоят все bugfix релизы в вашей ветке?

Закончившийся autovacuum — он был обычный или to prevent wraparound?

Что будет если руками сделать VACUUM FREEZE таблице?
...
Рейтинг: 0 / 0
15.03.2016, 20:32
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192730
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
VerusK,

а можно включить log_autovacuum_min_duration = 1000 (1000 мс) например и показать что в логах будет писаться?
...
Рейтинг: 0 / 0
15.03.2016, 20:35
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192734
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
vyegorovVerusKавтовакуумы приходят и уходят, такое ощущение, что он по всем таблицам проходится. Или так и должно быть? Я думал "эпоха" считается для каждой таблицы отдельно.
автовакуум должен пройти по всем таблицам, у которых age() > autovacuum_freeze_max_age. которые из ваших попадают под условие легко проверить, как и то, сколько осталось.

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

age (возраст) считается отдельно
а эпоха -- это количество циклов txid по беззнаковому (если не ошибаюсь) целому. оно как минимум одно для базы. как максимум -- для инстанса (не проверял).

----------------------------
скорее всего у него старый запуск вакуума произошёл во время висячей длинной транзакции -- вот они все и старые. он же туда не лазил. он проверяет зачем-то распределенные транзакции, хотя это лишнее.
...
Рейтинг: 0 / 0
15.03.2016, 20:39
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192752
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

- версия 9.4.5
- закончившийся autovacuum — to prevent wraparound, вообще сейчас только такие вакуумы и стартуют
- vacuum freeze не делал, не дает сделать запущенный автовакуум

Alexius, ничего в логах не увидел про автовакуум
...
Рейтинг: 0 / 0
15.03.2016, 21:10
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192754
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

попробовал запустить на другой таблице и получил вот такое сообщение:
Код: powershell
1.
2.
3.
4.
5.
6.
7.
ho2=# VACUUM FREEZE action_flows;
WARNING:  oldest xmin is far in the past
HINT:  Close open transactions soon to avoid wraparound problems.
WARNING:  oldest xmin is far in the past
HINT:  Close open transactions soon to avoid wraparound problems.
DEBUG:  transaction ID wrap limit is 2604342112, limited by database with OID 19489
DEBUG:  MultiXactId wrap limit is 2147483648, limited by database with OID 19489
...
Рейтинг: 0 / 0
15.03.2016, 21:13
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192783
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

А кол-во таблиц у которых age() > 2e8 уменьшается?

Я бы поступил так:
- выцыганил бы окно на несколько часов
- опустил бы базу аккуратно (pg_ctl -m fast stop)
- накатил бы 9.4.6, хоть и нет там ничего вокруг autovacuum'а
- поменял бы `listen_addresses` на умолчательный — только локальные подключения
- запуил бы базу и мониторил бы как она морозиться и есть ли эффект


Далее по обстановке.

P.S. Всё же приведите вывод запроса по сессиям который я постил.
...
Рейтинг: 0 / 0
15.03.2016, 22:53
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192809
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

Код: sql
1.
select * from pg_database


?
...
Рейтинг: 0 / 0
16.03.2016, 00:10
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192811
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
вернее:

Код: sql
1.
select oid, * from pg_database
...
Рейтинг: 0 / 0
16.03.2016, 00:13
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192813
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
хотя нет -- oid увидел на скринах
...
Рейтинг: 0 / 0
16.03.2016, 00:15
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192815
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

проведите замер темпов прироста txid_current() -- чтобы понять ,что у вас там крутится. а то вдруг у вас сейвпойнт на сейвпойнте сидит и сейпойнтом погоняет.
...
Рейтинг: 0 / 0
16.03.2016, 00:21
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192851
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
VerusKvyegorov,

попробовал запустить на другой таблице и получил вот такое сообщение:
Код: powershell
1.
2.
3.
4.
5.
6.
7.
ho2=# VACUUM FREEZE action_flows;
WARNING:  oldest xmin is far in the past
HINT:  Close open transactions soon to avoid wraparound problems.
WARNING:  oldest xmin is far in the past
HINT:  Close open transactions soon to avoid wraparound problems.
DEBUG:  transaction ID wrap limit is 2604342112, limited by database with OID 19489
DEBUG:  MultiXactId wrap limit is 2147483648, limited by database with OID 19489



Ок попробую я вмешаться.

Номер 1:
Код: plsql
1.
select * from pg_stat_activity where now()-xact_start>'120 min'::interval;


на мастер базе что то показывает?

Номер 2:
Вы кажется упоминали про реплику, на реплике что показывают:
Код: plsql
1.
[SRC PLSQL]show hot_standby_feedback;

[/SRC]
Код: plsql
1.
select * from pg_stat_activity where now()-xact_start>'120 min'::interval;



Номер 3:
На мастере
show max_replication_slots;
и
Код: plsql
1.
select pg_current_xlog_location(),pg_xlog_location_diff(pg_current_xlog_location(), replay_location) as replay_lag,* from pg_stat_replication;



Я почему то склоняюсь к том что проблему найдем на вопросе 2.

--
Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
16.03.2016, 03:30
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192873
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Maxim Boguk,

1. https://www.dropbox.com/s/q6j532240cnwea6/select___from_pg_stat_activity_where_now.csv?dl=0
2. hot_standby_feedback - off
Код: plsql
1.
select * from pg_stat_activity where now()-xact_start>'120 min'::interval;

- ничего не показал
3. max_replication_slots - 3
https://www.dropbox.com/s/qp8mcgrbeq88uej/select_pg_current_xlog_location___pg_xlo.csv?dl=0

qwwq,
txid_current - 5229543838
...
Рейтинг: 0 / 0
16.03.2016, 07:42
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192882
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK<>
qwwq,
txid_current - 5229543838одна буква -- это ниачом
темпы нужны. т.е. сколько их у вас в час
<<10^6
~10^6
>>10^6
...
Рейтинг: 0 / 0
16.03.2016, 08:23
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192887
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

1023262 - столько набежало сейчас, не в пиковое время, примерно за 45 минут, т.е. в час примерно 1364400. В пиковые часы будет в 2 раза больше

P.S. все началось примерно с того как мы ввели replication slots и завели Slony. Было это почти одновоременно. replication slots как то могли повлиять? Просто есть смысл попробовать выключить все по очереди
...
Рейтинг: 0 / 0
16.03.2016, 08:30
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192900
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

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

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


да, выводите не только age() но и сам frozentxid -- чтобы видеть, слистываются они у вас, или стоят на месте.
...
Рейтинг: 0 / 0
16.03.2016, 08:43
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39192905
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

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

Код: plsql
1.
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

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

у меня это выдает вот такую картину:
434138884506858465506858465313794789376292 GB172484138884456858465506858465169881706496158 GB14634817289464917789464917742399334404044 MB12661582806748390696748390698927641685 MB191842429939154920939154920106496104 kB19387969400585539400585539830496 kB1
...
Рейтинг: 0 / 0
16.03.2016, 11:40
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39193131
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
VerusKAlexius, ничего в логах не увидел про автовакуум

странно, а reload после правки конфига делался? должны записи о прошедших автовакуумах появляться.
...
Рейтинг: 0 / 0
16.03.2016, 11:58
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39193134
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
VerusK,

хм, скорость никакая совсем. попробуйте autovacuum_vacuum_cost_delay (именно autovacuum, а не просто vacuum) снизить до 5ms.
...
Рейтинг: 0 / 0
16.03.2016, 12:08
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39193190
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

т.е. надо просто ждать пока оно провернет этот кусок? очень страшно, что не успеет :)
...
Рейтинг: 0 / 0
16.03.2016, 14:36
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39193780
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
только что было очень странно, начался автовакуум для таблицы заново, до этого длившийся 1200+минут, но нет в логах ничего о завершении предыдущего
...
Рейтинг: 0 / 0
16.03.2016, 19:54
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39193794
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
VerusK,

а в логах нет строки вида canceling autovacuum task ? некоторые блокировки могут автовакуум прибивать.
...
Рейтинг: 0 / 0
16.03.2016, 20:28
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39193813
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
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
1.
197920296;198097056;200687136;3188185417;819149365248;'763 GB';115


т.е. ко мне пришли сейчас, в т.ч., 2 большие партиции, максимум их будет 3. все воркеры забиться не должны. но подсобрать ещё хвостов из следующей пачки бунч может. (простая волна с отрицательной нелинейностью укручается кзади. -- типичная "дорожная пробка", в которую впиливаются догоняющие)
...
Рейтинг: 0 / 0
17.03.2016, 11:02
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39194158
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

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

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

я так думаю.

и да , все время мониторьте длинные транзакции в стат--активити.
...
Рейтинг: 0 / 0
17.03.2016, 11:32
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39194206
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

похоже, что он не меняется совсем, вот данные вчерашние:
Код: plsql
1.
public	leads_y2015_m9	432450377	506858465	506858465



вот данные сегодняшние:
Код: plsql
1.
public	leads_y2015_m9	488912641	506858465	506858465




похоже все плохо?
...
Рейтинг: 0 / 0
17.03.2016, 11:55
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39194220
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

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

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


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

если не уверены -- то навешивайте мониторинг. При следующем "окончании фриза" без сдвига фрозена -- просто снимите табличку с автовакуума, и запустите VACUUM FREEZE руками. прямо на сервере. скажем в screen-е.
...
Рейтинг: 0 / 0
17.03.2016, 12:06
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39194252
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

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

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

3. Какая у вас транзакционная активность?
 
Смотреть так
Код: sql
1.
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
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
1.
age(now(), backend_start)::interval(0)

,
или пользуйтесь полуоткрытыми интервалами (что предпочтительней).
...
Рейтинг: 0 / 0
17.03.2016, 13:22
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39194329
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

idle in transaction - запросы от приложения, отрабатывают быстро
сессия в ожидании то появляется, то исчезает, тоже отрабатывает быстро
...
Рейтинг: 0 / 0
17.03.2016, 13:27
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39194332
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
qwwq,

А поделитесь правильным вариантом этого запроса, который бы работал на версиях начиная с 9.0?
...
Рейтинг: 0 / 0
17.03.2016, 13:28
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39194352
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
vyegorovqwwq,

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

потом расскажете, если сочтёте нужным, при чем тут версия и прочие обстоятельства

ещё раз -- дико извиняюсь
...
Рейтинг: 0 / 0
17.03.2016, 13:36
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39194413
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

Вы говорите, что всё отрабатывает быстро, ничего необычного нету.
Однако при этом по кругу бегает автовакуум и когда это кончиться не ясно.

Нестыковка.
...
Рейтинг: 0 / 0
17.03.2016, 14:08
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39194417
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
qwwqили квантуйте хотя бы секундами, или пользуйтесь полуоткрытыми интервалами (что предпочтительней).
Да, я понял о чём вы, спасибо.
...
Рейтинг: 0 / 0
17.03.2016, 14:09
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39194423
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
vyegorov,

не за что

этот антипаттерн распространяет 1С. ну так у них время квантованное. А люди привыкают -- и лепят везде и всюду. не думая.
ещё раз извиняюсь
...
Рейтинг: 0 / 0
17.03.2016, 14:15
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195028
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Немного отсрочил автовакуумы увеличив лимиты. Пытаюсь сделать VACUUM FREEZE вручную, но на любую таблицу получаю такой ответ:
Код: plsql
1.
2.
3.
4.
5.
sql> VACUUM FREEZE leads_y2016_m3
[2016-03-18 07:30:18] oldest xmin is far in the past
[2016-03-18 07:30:18] oldest xmin is far in the past
[2016-03-18 07:30:18] transaction ID wrap limit is 2654342112, limited by database with OID 19489
[2016-03-18 07:30:18] MultiXactId wrap limit is 2147483648, limited by database with OID 19489



и естественно age не меняется и фрозентхид тоже
...
Рейтинг: 0 / 0
18.03.2016, 07:36
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195031
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Заметили так же, что если делаешь TRUNCATE на таблицу, то сбрасывается age и меняется фрозентхид
...
Рейтинг: 0 / 0
18.03.2016, 07:45
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195047
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusKЗаметили так же, что если делаешь TRUNCATE на таблицу, то сбрасывается age и меняется фрозентхид"на третий день зоркий сокол ..."


у вас, по сути, создаётся новая таблица. естественно её возраст -- 0, и запись об этом появляется в системной таблице пж-класс, в поле "зафройзено_на_момент:"
-- вы ожыдали чего--то другого ?
...
Рейтинг: 0 / 0
18.03.2016, 08:42
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195051
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK <..1..>

и естественно <2> age не меняется и фрозентхид тожевот это как раз и не естественно

совсем не понял, как вы одно<2> выводите из другого <..1..>.

если при ручном фризе фрозентхид не меняется -- доставайте духовое ружжо, надевайте чистое и стреляйтесь.

только сначала напишите посмертную записку на postgresql.org -- "в моей смерти , " и всё такое.
...
Рейтинг: 0 / 0
18.03.2016, 08:49
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195056
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

при ручном он должен меняться в любом случае при запуске на отдельную таблицу? Я сейчас запустил VACUUM FREEZE на всю БД - это имеет вообще какой-то смысл?
...
Рейтинг: 0 / 0
18.03.2016, 08:55
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195064
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

Имеет.

Я рекомендую остановить экземпляр, закрыть его для подключений и закончить заморозку всех баз , включая postgres и шаблоны.
...
Рейтинг: 0 / 0
18.03.2016, 09:10
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195067
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

это продакшен база, даунтайм недопустим, есть варианты без остановки?
...
Рейтинг: 0 / 0
18.03.2016, 09:14
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195122
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusKvyegorov,

это продакшен база, даунтайм недопустим, есть варианты без остановки?

вариант без останова -- застрелиться, как честному человеку.

какая у вас версия, я уже забыл.
тут вот пишут:
http://www.postgresql.org/docs/9.4/static/release-9-3-5.html
про E.14.2. Changes (скорее всего не про вас, т.к. про пж--апгрейл, но чем не шутит)
...
Рейтинг: 0 / 0
18.03.2016, 10:32
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195137
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

версия 9.4.5
после фриза на весь инстанс ничего не изменилось
...
Рейтинг: 0 / 0
18.03.2016, 10:47
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195152
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

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

можно растянуть удовольствие --- поднять клон слонами или лондайстом (но не потоковой) -- и попробовать перейти на него с минимальным лагом. но лаг -- будет.

и да, вы уже написали хаасу там [Robert Haas], или какому либо иному гурью по вакууму ? именно по вакууму, а не на деревню дедушке олегу или теодору ?

что вы тут ещё делаете, не совсем понятно.
...
Рейтинг: 0 / 0
18.03.2016, 10:58
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195198
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

У вас симтомы таковы, что фриз не происходит. В результате вы неминуемо приближаетесь к точке, когда база сама встанет, чтобы избежать wraparound'а. И тот факт, что это продукция, ничего не поменяет. Просите окно на самое глухое вермя, на несколько часов, останавливайте и лечите.

Вам нужно собрать детальный анамнез: версия, все настройки, описание железа, данные по базам/таблицам/сессиям/репликам/нагрузке, приложить детальные логи за ту неделю, что всё это тянется.

Писать лучше в pgsql-general, его смотрят практически все и если это баг, то он быстро уйдет в обсуждение в pgsql-hackers. Сейчас готовят новые релизы, так что не томите. Ваш анамнез в виде файлов добавьте (как приложения к письму), не надо простыню из всех конфигов копипастить.

Самые подкованные из разработчиков по вакууму — Альваро Херера (он писал автовакуум) и Том Лейн (он в любом вопросе самый подкованный).
...
Рейтинг: 0 / 0
18.03.2016, 11:42
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195208
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
отписал сразу в хакерс, расписал, постарался как можно подробнее
...
Рейтинг: 0 / 0
18.03.2016, 11:50
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195292
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusKотписал сразу в хакерс, расписал, постарался как можно подробнее
Чёт нету ничего. Письмо точно ушло? И на какой адрес?
...
Рейтинг: 0 / 0
18.03.2016, 12:54
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195307
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

получил пока такое:
Your message to pgsql-hackers has been delayed, and requires the approval
of the moderators, for the following reason(s):

The author (XXX)
is not a member of any of the restrict_post groups.

If you do not wish the message to be posted, or have other concerns,
please send a message to the list owners at the following address:
pgsql-hackers-owner@postgresql.org
...
Рейтинг: 0 / 0
18.03.2016, 13:06
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195359
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusKотписал сразу в хакерс, расписал, постарался как можно подробнее



торопиться не надо, да
...
Рейтинг: 0 / 0
18.03.2016, 13:51
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195635
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusK,

как ваши успехи ?
если будут новости -- отпишитесь, пожалуйста.
и ссылку киньте

спасибо
...
Рейтинг: 0 / 0
18.03.2016, 17:33
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195913
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

В общем сделали из реплики мастер, сделали на ней вакуум фриз, стопнули мастер, добили недостающие данные в новый мастер, перевели все на него, чиним старый мастер и вернемся обратно. На postgresql.org пока спросили только про длинные транзакции, но их у нас нет и не было.
...
Рейтинг: 0 / 0
19.03.2016, 08:25
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195934
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

www.postgresql.org/message-id/flat/CAM+o-ApLaXFLaieaVx5Dj1RKCx2OaLm5akJ909j8H8FLL5UJMg@mail.gmail.com
...
Рейтинг: 0 / 0
19.03.2016, 09:58
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39195936
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
 
Поправил ссылку
http://www.postgresql.org/message-id/flat/CAM+o-ApLaXFLaieaVx5Dj1RKCx2OaLm5akJ909j8H8FLL5UJMg@mail.gmail.com]на сообщение

Вы бы там продемонстрировали ситуацию:
- проверить age таблицы
- принудительно заморозить
- проверить age ещё раз

Может привлечёт больше внимания.
...
Рейтинг: 0 / 0
19.03.2016, 10:08
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39196011
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

на самом деле произошла какая-то магия, после того как перенесли все данные, отключили реплику, я удалил слоты репликации, очистил pg_xlog(установив новые точки) и завел БД, то почти у всех таблиц возраст сбросился. Затем я сделал ваккум фриз в сингл моде. Теперь выходит ошибка "Missing chunk 0 for toast value in pg_toast" - но как везде пишут, пробую сделать реиндекс этой таблицы и вакуум аналайз.

Кстати по завершении вакуум фриз в сингл мод:
Код: plsql
1.
2.
3.
2016-03-19 10:25:11 UTC   67595 WARNING:  some databases have not been vacuumed in over 2 billion transactions
2016-03-19 10:25:11 UTC   67595 DETAIL:  You might have already suffered transaction-wraparound data loss.
2016-03-19 10:25:11 UTC   67595 STATEMENT:  vacuum (verbose, freeze);


на сколько я понимаю, тут говорится, что мы уже теряли данные. Видимо мы не замечали какие именно.
...
Рейтинг: 0 / 0
19.03.2016, 14:21
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39196027
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
VerusKqwwq,
<> На postgresql.org пока спросили только про длинные транзакции, но их у нас нет и не было.
естественно проверяют сначала напрашивающееся.
если бы вы сразу отписались что активити пуста, а распределенных тоже уже нет -- возможно спросили бы ещё что--нть.

отпишите им всё

кстати, а как снимали распределённую ? вы же писали, что там (pg_prepared_xacts) у вас что--то висело когда--то.


странно, что на стендбай оно [проблема] не отреплицировалось. где-то тут может сермяга оказаться.
...
Рейтинг: 0 / 0
19.03.2016, 15:15
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39196086
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
qwwq,

pg_prepared_xacts не висело никогда, вроде даже тут об этом отписывался. Проблема, конечно же ушла на реплику, но мы сделали ее мастером и на ней провели вакуум фриз в сингл моде, что помогло и сейчас она работает исправно, пока что чиним мастер.
...
Рейтинг: 0 / 0
19.03.2016, 17:13
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39196093
drsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drsm
Участник
Robert Haas - Thursday, March 10, 2016 No More Full-Table Vacuums
авторInstead of whole-table vacuums, we now have aggressive vacuums, which will read every page in the table that isn't already known to be entirely frozen. If you have a large database which is mostly static but which has a comparatively small active portion, this change will massively reduce the impact of wraparound vacuuming. Users with multi-terabyte databases having non-trivial write activity will be especially happy about this change. An aggressive vacuum still figures to read more data than a regular vacuum, possibly a lot more. But at least it won't read the data that hasn't been touched since the last aggressive vacuum, and that's a big improvement.
...
Рейтинг: 0 / 0
19.03.2016, 17:20
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39196123
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
drsm,

Это будет только в 9.6, который выйдет в сентябре (по плану).
...
Рейтинг: 0 / 0
19.03.2016, 18:42
| Ответить | Цитировать | Написать  
Очень долгий autovacuum (to prevent wraparound)
    #39200951
daevy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
daevy
Гость
VerusK,

а всё ли ок со статой? покажите \dt+ pg_statistic
...
Рейтинг: 0 / 0
25.03.2016, 19:58
| Ответить | Цитировать | Написать  
104 сообщений из 104, показаны все 5 страниц
  все  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Очень долгий autovacuum (to prevent wraparound)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=53&tid=1997327]:
 0ms
get settings:
 8ms
get forum list:
 17ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 194ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 151ms
get tp. blocked users:
 1ms
others: 230ms
total:  624ms
созд. / загр.: 624ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]