From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bastian Voigt <post@bastian-voigt.de>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)
Date: Fri, 25 May 2007 10:18:45 -0400
Message-ID: <8588.1180102725@sss.pgh.pa.us> (raw)
In-Reply-To: <46569E6A.2060509@bastian-voigt.de>
References: <46569E6A.2060509@bastian-voigt.de>
Bastian Voigt <post@bastian-voigt.de> writes:
> Now my big big problem is that the database gets really really slow
> during these 20 minutes and after the vacuum process is running for a
> short time, many transactions show state "UPDATE waiting" in the process
> list. In my Java application server I sometimes get tons of deadlock
> Exceptions (waiting on ShareLock blahblah). The web frontend gets nearly
> unusable, logging in takes more than 60 seconds, etc. etc.
Hmm. That's a bit weird --- what are they waiting on exactly? Look in
pg_locks to see what the situation is. A vacuum per se ought not be
blocking any updates.
Aside from the recommendation to make the vacuums happen more frequently
instead of less so, you should experiment with vacuum_cost_delay and
related parameters. The idea is to reduce vacuum's I/O load so that it
doesn't hurt foreground response time. This means any individual vacuum
will take longer, but you won't need to care.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, post@bastian-voigt.de
Subject: Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)
In-Reply-To: <8588.1180102725@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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