Re: Insert Performance with WAL and Fsync - Mailing list pgsql-general

From Mike Schroepfer
Subject Re: Insert Performance with WAL and Fsync
Date
Msg-id 50D1DD22A3646047A6282C10311585123D070B@mail01.raplix.com
Whole thread Raw
In response to Insert Performance with WAL and Fsync  (Mike Schroepfer <mike@raplix.com>)
List pgsql-general
Andrew,

Thanks for the reply - responses below:

> > It appears the CPU utilization on both machines is very low
> (<15%)- so I'm
> > guessing it is mostly I/O overhead.
>
> Are you seeing anything due to swapping, &c?  What do memstat and
> friends tell you?

No swapping problems at all - lots of CPU and mem to go around (vmstat 5):

 procs     memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr s0 s1 s6 --   in   sy   cs us sy
id
 0 0 0 2140608 1820520 2 15  1  1  1  0  0  2  0  0  0  430  130   71  1  1
99
 0 0 0 2091848 1674728 21 65 0  0  0  0  0 67  0  0  0  806 2151  633 18 15
67
 0 0 0 2091848 1673928 21 52 0  0  0  0  0 65  0  0  0  806 2081  611 20 15
64
 0 0 0 2092472 1674008 12 19 0  8  8  0  0 39  0  0  0  634 1073  333 10  6
84

> We're using Solaris 7 and seeing considerably better performance than
> that (mind you' we've got some honkin' big hardware underneath, and a
> big RAID array with internal battery-backed smart caches, so I might
> not be the right person to ask).

What kind of numbers are you getting - so I can get an idea
of where I am relative.


> One thing I noticed is that the WAL commit_delay and siblings
> settings were a big help.  My theory was WAL was costing us too much,
> because we had such volume that WAL became a bottleneck -- it was
> firing too quickly.  My answer was to increase those settings; I
> noticed an immediate improvement.  I had to increase the segments as
> well, in order to keep up; this takes slightly longer to recover in
> case of a crash, of course, but not so long as to make the difference
> worth worrying about.

Can you share your config?  I've played with it without much help - I
probably
am missing something.



> > 1 36Gig 10000RPM SCSI Disk
>
> I'd also worry about this 1-disk set-up.  I'd be inclined to double
> the disk in order to put the WAL file on another spindle (or use RAID
> to speed things up, but that's a lot more disk).

Yeah - this is not a production system - I'm trying to do some testing
to understand our app's characteristics and hardware requirements.  I
certainly
would at least mirror for safety and would love to get the wal on a another
spindle.


> > Postgres 7.1.2 compiled using gcc
>
> There are a couple of issues that make it worth the upgrade to 7.1.3.
> See the archives.  Nothing to help your perf. though, if I recall.

Hmm - looked through the logs a good while ago and didn't see anything that
I was too
concerned about.  I'll double check tho - thanks!

> If I can think of anything else, I'll let you know.

Appreciate your help!

Mike


>
> A
> --
> ----
> Andrew Sullivan                               87 Mowat Avenue
> Liberty RMS                           Toronto, Ontario Canada
> <andrew@libertyrms.info>                              M6K 3E3
>                                          +1 416 646 3304 x110
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

pgsql-general by date:

Previous
From: will trillich
Date:
Subject: question about locking (and documentation thereof)
Next
From: Mike Schroepfer
Date:
Subject: Re: Insert Performance with WAL and Fsync