pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: Posrgres speed problem - solved?
5+ messages / 2 participants
[nested] [flat]
* Re: Posrgres speed problem - solved?
@ 2006-06-13 06:44 Ruben Rubio Rey <ruben@rentalia.com>
2006-06-13 08:11 ` Re: Posrgres speed problem - solved? Guido Neitzer <guido.neitzer@pharmaline.de>
0 siblings, 1 reply; 5+ messages in thread
From: Ruben Rubio Rey @ 2006-06-13 06:44 UTC (permalink / raw)
To: pgsql-performance
Tonight database has been vacumm full and reindex (all nights database
do it)
Now its working fine. Speed is as spected. I ll be watching that sql ...
Maybe the problem exists when database is busy, or maybe its solved ...
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Posrgres speed problem - solved?
2006-06-13 06:44 Re: Posrgres speed problem - solved? Ruben Rubio Rey <ruben@rentalia.com>
@ 2006-06-13 08:11 ` Guido Neitzer <guido.neitzer@pharmaline.de>
2006-06-13 08:17 ` Re: Posrgres speed problem - solved? Ruben Rubio Rey <ruben@rentalia.com>
0 siblings, 1 reply; 5+ messages in thread
From: Guido Neitzer @ 2006-06-13 08:11 UTC (permalink / raw)
To: Ruben Rubio Rey <ruben@rentalia.com>; +Cc: pgsql-performance
On 13.06.2006, at 8:44 Uhr, Ruben Rubio Rey wrote:
> Tonight database has been vacumm full and reindex (all nights
> database do it)
>
> Now its working fine. Speed is as spected. I ll be watching that
> sql ...
> Maybe the problem exists when database is busy, or maybe its
> solved ...
Depending on the usage pattern the nightly re-index / vacuum analyse
is suboptimal. If you have high insert/update traffic your
performance will decrease over the day and will only be good in the
morning hours and I hope this is not what you intend to have.
Autovacuum is the way to go, if you have "changing content". Perhaps
combined with vacuum analyse in a nightly or weekly schedule. We do
this weekly.
cug
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Posrgres speed problem - solved?
2006-06-13 06:44 Re: Posrgres speed problem - solved? Ruben Rubio Rey <ruben@rentalia.com>
2006-06-13 08:11 ` Re: Posrgres speed problem - solved? Guido Neitzer <guido.neitzer@pharmaline.de>
@ 2006-06-13 08:17 ` Ruben Rubio Rey <ruben@rentalia.com>
2006-06-13 10:33 ` Re: Posrgres speed problem - solved! Ruben Rubio Rey <ruben@rentalia.com>
0 siblings, 1 reply; 5+ messages in thread
From: Ruben Rubio Rey @ 2006-06-13 08:17 UTC (permalink / raw)
To: Guido Neitzer <guido.neitzer@pharmaline.de>; +Cc: pgsql-performance
Guido Neitzer wrote:
> On 13.06.2006, at 8:44 Uhr, Ruben Rubio Rey wrote:
>
>> Tonight database has been vacumm full and reindex (all nights
>> database do it)
>>
>> Now its working fine. Speed is as spected. I ll be watching that sql
>> ...
>> Maybe the problem exists when database is busy, or maybe its solved ...
>
>
> Depending on the usage pattern the nightly re-index / vacuum analyse
> is suboptimal. If you have high insert/update traffic your
> performance will decrease over the day and will only be good in the
> morning hours and I hope this is not what you intend to have.
>
> Autovacuum is the way to go, if you have "changing content". Perhaps
> combined with vacuum analyse in a nightly or weekly schedule. We do
> this weekly.
>
> cug
>
>
I ll configure autovacum. I ll write if problem is solved.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Posrgres speed problem - solved!
2006-06-13 06:44 Re: Posrgres speed problem - solved? Ruben Rubio Rey <ruben@rentalia.com>
2006-06-13 08:11 ` Re: Posrgres speed problem - solved? Guido Neitzer <guido.neitzer@pharmaline.de>
2006-06-13 08:17 ` Re: Posrgres speed problem - solved? Ruben Rubio Rey <ruben@rentalia.com>
@ 2006-06-13 10:33 ` Ruben Rubio Rey <ruben@rentalia.com>
2006-06-13 11:48 ` Re: Posrgres speed problem - solved! Guido Neitzer <guido.neitzer@pharmaline.de>
0 siblings, 1 reply; 5+ messages in thread
From: Ruben Rubio Rey @ 2006-06-13 10:33 UTC (permalink / raw)
To: pgsql-performance
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?
Thanks everyone!!!
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Posrgres speed problem - solved!
2006-06-13 06:44 Re: Posrgres speed problem - solved? Ruben Rubio Rey <ruben@rentalia.com>
2006-06-13 08:11 ` Re: Posrgres speed problem - solved? Guido Neitzer <guido.neitzer@pharmaline.de>
2006-06-13 08:17 ` Re: Posrgres speed problem - solved? Ruben Rubio Rey <ruben@rentalia.com>
2006-06-13 10:33 ` Re: Posrgres speed problem - solved! Ruben Rubio Rey <ruben@rentalia.com>
@ 2006-06-13 11:48 ` Guido Neitzer <guido.neitzer@pharmaline.de>
0 siblings, 0 replies; 5+ messages in thread
From: Guido Neitzer @ 2006-06-13 11:48 UTC (permalink / raw)
To: 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
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2006-06-13 11:48 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-06-13 06:44 Re: Posrgres speed problem - solved? Ruben Rubio Rey <ruben@rentalia.com>
2006-06-13 08:11 ` Guido Neitzer <guido.neitzer@pharmaline.de>
2006-06-13 08:17 ` Ruben Rubio Rey <ruben@rentalia.com>
2006-06-13 10:33 ` Re: Posrgres speed problem - solved! Ruben Rubio Rey <ruben@rentalia.com>
2006-06-13 11:48 ` Re: Posrgres speed problem - solved! Guido Neitzer <guido.neitzer@pharmaline.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox