pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Worky Workerson <worky.workerson@gmail.com>
To: Luke Lonergan <llonergan@greenplum.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Best COPY Performance
Date: Tue, 31 Oct 2006 16:11:00 -0400
Message-ID: <ce4072df0610311211i3944344dx69a4be966cb548c0@mail.gmail.com> (raw)
In-Reply-To: <C1651375.523A%llonergan@greenplum.com>
References: <ce4072df0610251126w1eaca026x7751256f962b131f@mail.gmail.com>
	<C1651375.523A%llonergan@greenplum.com>

> > And here are the dd results for 16GB RAM, i.e. 4,000,000 8K blocks:
>
> So, if we divide 32,000 MB by the real time, we get:
> /data (data):
> 89 MB/s write
> 38 MB/s read
... snip ...
> The read speed on your /data volume is awful to the point where you should
> consider it broken and find a fix.  A quick comparison: the same number on a
> 16 drive internal SATA array with 7200 RPM disks gets 950 MB/s read, about
> 25 times faster for about 1/4 the price.

I managed to get approval to shut down the Oracle instance and reran
the dd's on the SAN (/data) and came up with about 60MB/s write (I had
missed the 'sync' in the previous runs) and about 58 MB/s read, still
no comparison on your SATA arrary.  Any recommendations on what to
look at to find a fix?  One thing which I never mentioned was that I
am using ext3 mounted with noatime,data=writeback.

An interesting note (at least to me) is the inverse relationship
between free memory and bo when writing with dd, i.e:

$ vmstat 5
r b   swpd   free   buff   cache si  so bi     bo   in  cs us sy id wa
0 3 244664 320688 23588 15383120  0   0  0     28 1145 197  0  1 74 25
2 6 244664 349488 22276 15204980  0   0  0     24 1137 188  0  1 75 25
2 6 244664  28264 23024 15526552  0   0  0  65102 1152 335  0 12 60 28
2 4 244664  28968 23588 15383120  0   0  1 384386 1134 372  0 19 34 47
1 5 244664  28840 23768 15215728  0   0  1 438482 1144 494  0 24 33 43
0 5 247256  41320 20144 15212788  0 524  0  57062 1142 388  0  6 43 51
1 6 247256  29096 19588 15226788  0   0  5  60999 1140 391  0 15 42 43

Is this because of the kernel attempting to cache the file in memory?



view thread (52+ messages)  latest in thread

Message-ID: <ce4072df0610311211i3944344dx69a4be966cb548c0@mail.gmail.com>
Permalink:  ../ce4072df0610311211i3944344dx69a4be966cb548c0@mail.gmail.com/
Also on:    postgresql.org/message-id/ce4072df0610311211i3944344dx69a4be966cb548c0@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: worky.workerson@gmail.com, llonergan@greenplum.com
  Subject: Re: Best COPY Performance
  In-Reply-To: <ce4072df0610311211i3944344dx69a4be966cb548c0@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