Re: 8.3 / 8.2.6 restore comparison

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.3 / 8.2.6 restore comparison
Date: 2008-02-08 00:37:39
Message-ID: 20080207163739.208b0d88@jd-laptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 07 Feb 2008 19:20:26 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Looks to me like you're disk-bound (and your kernel is pretty bad at
> distinguishing "idle" from "disk wait" states). Plain COPY into an
> index-less table ought to be writing fairly linearly, so I'm surprised
> you aren't able to get more out of the disk. Have you got WAL on
> a separate spindle from the database?

I didn't, but do now and am testing. The way this is currently designed
is:

/data1 (8 disks RAID 10)
/data2 (8 disks RAID 10)
/pg_xlogs (2 disks RAID 1)

/data1 is what is primarily written against for the first couple of
hours and then it will switch to data2 because of table spaces. However
either way, we should expect (I would think) to see at least 100 megs a
second on an 8 Disk RAID 10. It is SCSI.

vmstat -adSK 5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free inact active si so bi bo in cs us sy id wa
1 1 160 6534048 23711184 1434532 0 0 1571 387 0 0 10 7 71 12
1 1 160 6206560 23898644 1573680 0 0 18168 23851 2684 1647 11 3 84 2
1 2 160 5887072 24080840 1711060 0 0 17655 58395 3322 1762 11 3 74 11
2 2 160 5546160 24275268 1856108 0 0 18681 61834 3302 1838 11 3 74 11
1 2 160 5363432 24383836 1933028 0 0 13043 52353 3247 1578 12 2 74 11
1 1 160 5295336 24423764 1963808 0 0 4997 39778 2865 1310 12 1 75 12
1 0 160 5284184 24426444 1971608 0 0 385 6967 2087 955 13 1 84 3
1 0 160 5274608 24429180 1978236 0 0 384 1009 2030 958 13 0 87 0
1 0 160 5265408 24431976 1984688 0 0 410 946 1780 656 12 0 87 0
1 1 160 5224912 24453296 2003700 0 0 1998 23168 2419 1163 12 1 79 8
1 2 160 5005048 24605300 2069236 0 0 18270 41342 2942 1721 12 2 76 10
1 2 160 4816016 24748120 2117208 0 0 19014 37165 3014 1702 12 2 72 15
1 1 160 4618064 24894476 2167412 0 0 19091 15226 2517 1626 12 2 83 3
1 1 160 4423376 25039072 2218324 0 0 18603 10398 2585 1644 12 2 84 3
1 1 160 4223568 25187592 2268816 0 0 19475 10326 2511 1666 12 2 84 2
1 1 160 4023056 25337080 2319844 0 0 19450 10601 2462 1543 12 2 84 2
1 1 160 3821328 25487664 2370328 0 0 19834 10657 2454 1540 12 2 84 2
1 1 160 3617616 25640832 2420820 0 0 20398 11202 2536 1678 12 2 84 2
1 2 160 3410040 25795488 2473800 0 0 20090 29063 2756 1680 12 2 76 10
1 1 160 3189064 25957688 2531996 0 0 20321 13745 2523 1595 12 2 83 4

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-02-08 00:52:04 Re: PostgreSQL 8.4 development plan
Previous Message Tom Lane 2008-02-08 00:20:26 Re: 8.3 / 8.2.6 restore comparison