Re: 12 hour table vacuums

From: Ron St-Pierre <ron(dot)pgsql(at)shaw(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: 12 hour table vacuums
Date: 2007-10-23 16:43:08
Message-ID: 471E249C.2090009@shaw.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
>
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ron St-Pierre 2007-10-23 16:52:52 Re: 12 hour table vacuums
Previous Message Bill Moran 2007-10-23 16:41:48 Re: 12 hour table vacuums