Re: Configuring PostgreSQL to minimize impact of checkpoints

From: Vivek Khera <khera(at)kcilink(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Configuring PostgreSQL to minimize impact of checkpoints
Date: 2004-05-12 18:57:58
Message-ID: x7k6zhlbgp.fsf@yertle.int.kciLink.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

>>>>> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

TL> Jack Orenstein <jao(at)geophile(dot)com> writes:
>> I'm looking at one case in which two successive transactions, each
>> updating a handful of records, take 26 and 18 *seconds* (not msec) to
>> complete. These transactions normally complete in under 30 msec.

TL> I've seen installations in which it seemed that the "normal" query load
TL> was close to saturating the available disk bandwidth, and the extra load
TL> imposed by a background VACUUM just pushed the entire system's response
TL> time over a cliff. In an installation that has I/O capacity to spare,

me stand up waving hand... ;-) This is my only killer problem left.
I always peg my disk usage at 100% when vacuum runs, and other queries
are slow too. When not running vacuum, my queries are incredibly
zippy fast, including joins and counts and group by's on upwards of
100k rows at a time.

TL> I suspect that the same observations hold true for checkpoints, though
TL> I haven't specifically seen an installation suffering from that effect.

I don't see that. But I also set checkpoint segments to about 50 on
my big server.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera(at)kciLink(dot)com Rockville, MD +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Vivek Khera 2004-05-12 19:05:05 Re: Configuring PostgreSQL to minimize impact of
Previous Message scott.marlowe 2004-05-12 13:44:37 Re: [PERFORM] Quad processor options