Re: 12 hour table vacuums
От | Ron St-Pierre |
---|---|
Тема | Re: 12 hour table vacuums |
Дата | |
Msg-id | 471E249C.2090009@shaw.ca обсуждение исходный текст |
Ответ на | Re: 12 hour table vacuums (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Tom Lane wrote: > Here is your problem: > > >> vacuum_cost_delay = 200 >> > > If you are only vacuuming when nothing else is happening, you shouldn't > be using vacuum_cost_delay at all: set it to 0. In any case this value > is probably much too high. I would imagine that if you watch the > machine while the vacuum is running you'll find both CPU and I/O load > near zero ... which is nice, unless you would like the vacuum to finish > sooner. > Yeah, I've noticed that CPU, mem and I/O load are really low when this is running. I'll change that setting. > In unrelated comments: > > >> maintenance_work_mem = 786432 >> > > That seems awfully high, too. > > Any thoughts on a more reasonable value? >> max_fsm_pages = 70000 >> > > And this possibly too low --- The default appears to be 20000, so I upped it to 70000. I'll try 160000 (max_fsm_relations*16). > are you sure you are not leaking disk > space? > > What do you mean leaking disk space? >> stats_start_collector = off >> stats_command_string = on >> stats_block_level = on >> stats_row_level = on >> > > These are not self-consistent. > > regards, tom lane > >
В списке pgsql-performance по дате отправления: