Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group