From: | Guido Neitzer <guido(dot)neitzer(at)pharmaline(dot)de> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Posrgres speed problem - solved! |
Date: | 2006-06-13 11:48:26 |
Message-ID: | 14F7CD8C-D01B-4585-A909-604C4260B668@pharmaline.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 13.06.2006, at 12:33 Uhr, Ruben Rubio Rey wrote:
> Seems autovacumm is working fine. Logs are reporting that is being
> useful.
>
> But server load is high. Is out there any way to stop "autovacumm"
> if server load is very high?
Look at the cost settings for vacuum and autovacuum. From the manual:
"During the execution of VACUUM and ANALYZE commands, the system
maintains an internal
counter that keeps track of the estimated cost of the various I/O
operations that are performed. When
the accumulated cost reaches a limit (specified by
vacuum_cost_limit), the process performing
the operation will sleep for a while (specified by
vacuum_cost_delay). Then it will reset the
counter and continue execution.
The intent of this feature is to allow administrators to reduce the I/
O impact of these commands on
concurrent database activity. There are many situations in which it
is not very important that mainte-
nance commands like VACUUM and ANALYZE finish quickly; however, it is
usually very important that
these commands do not significantly interfere with the ability of the
system to perform other database
operations. Cost-based vacuum delay provides a way for administrators
to achieve this."
cug
From | Date | Subject | |
---|---|---|---|
Next Message | PFC | 2006-06-13 11:56:47 | Re: Interesting slow query |
Previous Message | Luke Lonergan | 2006-06-13 11:33:19 | Re: 64-bit vs 32-bit performance ... backwards? |