pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Christopher Petrilli <petrilli@gmail.com>
To: Vivek Khera <vivek@khera.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: Impact of checkpoint_segments under continual load conditions
Date: Mon, 18 Jul 2005 14:45:35 -0400
Message-ID: <59d991c405071811457ccdd3f1@mail.gmail.com> (raw)
In-Reply-To: <A50B8A1F-71A1-4F63-A5F4-1AA58F89557D@khera.org>
References: <59d991c4050717100874c08a86@mail.gmail.com>
	<A50B8A1F-71A1-4F63-A5F4-1AA58F89557D@khera.org>

On 7/18/05, Vivek Khera <vivek@khera.org> wrote:
> 
> On Jul 17, 2005, at 1:08 PM, Christopher Petrilli wrote:
> 
> > Normally, checkpoint_segments can help absorb some of that, but my
> > experience is that if I crank the number up, it simply delays the
> > impact, and when it occurs, it takes a VERY long time (minutes) to
> > clear.
> 
> There comes a point where your only recourse is to throw hardware at
> the problem.  I would suspect that getting faster disks and splitting
> the checkpoint log to its own RAID partition would help you here.
> Adding more RAM while you're at it always does wonders for me :-)

My concern is less with absolute performance, than with the nosedive
it goes into.  I published some of my earlier findings and comparisons
on my blog, but there's a graph here:

http://blog.amber.org/diagrams/comparison_mysql_pgsql.png

Notice the VERY steep drop off.  I'm still trying to get rid of it,
but honestly, am not smart enough to know where it's originating.  I
have no desire to ever use MySQL, but it is a reference point, and
since I don't particularly need transactional integrity, a valid
comparison.

Chris
-- 
| Christopher Petrilli
| petrilli@gmail.com



view thread (28+ messages)  latest in thread

Message-ID: <59d991c405071811457ccdd3f1@mail.gmail.com>
Permalink:  ../59d991c405071811457ccdd3f1@mail.gmail.com/
Also on:    postgresql.org/message-id/59d991c405071811457ccdd3f1@mail.gmail.com

 · 

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: petrilli@gmail.com, vivek@khera.org
  Subject: Re: Impact of checkpoint_segments under continual load conditions
  In-Reply-To: <59d991c405071811457ccdd3f1@mail.gmail.com>

* 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