On Fri, 07 Aug 2009 15:42:35 +0200, Kevin Grittner
<kevin.gritt...@wicourts.gov> wrote:
Pierre Frédéric Caillaud<li...@peufeu.com> wrote:
tablespace is a RAID5 of 3 drives, xlog in on a RAID1 of 2 drives,
but it does it too if I put the tablespace and data on the same
volume.
it starts out relatively fast :
si so bi bo in cs us sy id wa
0 0 0 43680 2796 19162 42 18 37 3
0 0 0 45515 3165 20652 44 17 35 4
0 0 0 43130 3046 21991 43 17 38 2
then here it starts to slow down : check "bo" output
0 0 181 24439 577 3541 31 6 40 23
0 0 176 17258 292 1324 31 4 43 22
0 0 0 18626 162 693 35 3 49 12
0 0 1 21554 235 1362 31 5 50 14
0 0 0 19177 324 2053 35 4 50 12
0 0 0 19208 206 1155 36 4 48 12
0 0 1 20740 215 1117 33 4 50 13
0 0 0 20154 258 1100 32 4 50 14
0 0 0 20355 316 2056 34 5 49 12
... and it stays like this until the end of the INSERT...
I don't know if this is it, but we tend to see outrageously high
performance at the start of a benchmark because of the battery-backed
cache in the RAID controller. Every write comes back immediately
after copying the data to RAM. After a while the cache gets filled
and you settle down to a steady state. If it's not BBU with
write-back enabled, perhaps you have drives that lie about write
completion?
-Kevin
I'm answering my own question : at the beginning of the run, postgres
creates a 800MB temporary file, then it fills the table, then deletes the
temp file.
Is this because I use generate_series to fill the test table ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
