pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: PFC <lists@boutiquenumerique.com>
To: Christopher Petrilli <petrilli@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Vivek Khera <vivek@khera.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: Impact of checkpoint_segments under continual load conditions
Date: Tue, 19 Jul 2005 17:33:21 +0200
Message-ID: <op.st52tvunth1vuj@localhost> (raw)
In-Reply-To: <59d991c405071907482bb0689b@mail.gmail.com>
References: <59d991c4050717100874c08a86@mail.gmail.com>
	<A50B8A1F-71A1-4F63-A5F4-1AA58F89557D@khera.org>
	<59d991c405071811457ccdd3f1@mail.gmail.com>
	<16394.1121715156@sss.pgh.pa.us>
	<59d991c405071812342e290f57@mail.gmail.com>
	<16794.1121718743@sss.pgh.pa.us>
	<59d991c405071907482bb0689b@mail.gmail.com>


	What happens if, say at iteration 6000 (a bit after the mess starts), you  
pause it for a few minutes and resume. Will it restart with a plateau like  
at the beginning of the test ? or not ?
	What if, during this pause, you disconnect and reconnect, or restart the  
postmaster, or vacuum, or analyze ?


> On 7/18/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > The table has 15 columns, 5 indexes (character, inet and timestamp).
>> > No foreign keys. The only other thing running on the machine was the
>> > application actually DOING the benchmarking, written in Python
>> > (psycopg), but it was, according to top, using less than 1% of the
>> > CPU.  It was just talking through a pipe to a psql prompt to do the
>> > COPY.
>>
>> Sounds pretty plain-vanilla all right.
>>
>> Are you in a position to try the same benchmark against CVS tip?
>> (The nightly snapshot tarball would be plenty close enough.)  I'm
>> just wondering if the old bgwriter behavior of locking down the
>> bufmgr while it examined the ARC/2Q data structures is causing this...
>
> Tom,
>
> It looks like the CVS HEAD is definately "better," but not by a huge
> amount.  The only difference is I wasn't run autovacuum in the
> background (default settings), but I don't think this explains it.
> Here's a graph of the differences and density of behavior:
>
> http://blog.amber.org/diagrams/pgsql_copy_803_cvs.png
>
> I can provide the raw data.  Each COPY was 500 rows.  Note that fsync
> is turned off here.  Maybe it'd be more stable with it turned on?
>
> Chris





view thread (28+ messages)  latest in thread

Message-ID: <op.st52tvunth1vuj@localhost>
Permalink:  ../op.st52tvunth1vuj@localhost/
Also on:    postgresql.org/message-id/op.st52tvunth1vuj@localhost

 · 

reply

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: lists@boutiquenumerique.com, petrilli@gmail.com, tgl@sss.pgh.pa.us, vivek@khera.org
  Subject: Re: Impact of checkpoint_segments under continual load conditions
  In-Reply-To: <op.st52tvunth1vuj@localhost>

* 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