From: | "Jeffrey Baker" <jwbaker(at)gmail(dot)com> |
---|---|
To: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Fusion-io ioDrive |
Date: | 2008-07-05 06:41:38 |
Message-ID: | fd145f7d0807042341p38cb505dl5140ee27e103d1dc@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Jul 1, 2008 at 5:18 PM, Jeffrey Baker <jwbaker(at)gmail(dot)com> wrote:
> I recently got my hands on a device called ioDrive from a company
> called Fusion-io. The ioDrive is essentially 80GB of flash on a PCI
> card.
[...]
> Service Time Percentile, millis
> R/W TPS R-O TPS 50th 80th 90th 95th
> RAID 182 673 18 32 42 64
> Fusion 971 4792 8 9 10 11
Essentially the same benchmark, but on a quad Xeon 2GHz with 3GB main
memory, and the scale factor of 300. Really all we learn from this
exercise is the sheer futility of throwing CPU at PostgreSQL.
R/W TPS: 1168
R-O TPS: 6877
Quadrupling the CPU resources and tripling the RAM results in a 20% or
44% performance increase on read/write and read-only loads,
respectively. The system loafs along with 2-3 CPUs completely idle,
although oddly iowait is 0%. I think the system is constrained by
context switch, which is tens of thousands per second. This is a
problem with the ioDrive software, not with pg.
Someone asked for bonnie++ output:
Block output: 495MB/s, 81% CPU
Block input: 676MB/s, 93% CPU
Block rewrite: 262MB/s, 59% CPU
Pretty respectable. In the same ballpark as an HP MSA70 + P800 with
25 spindles.
-jwb
From | Date | Subject | |
---|---|---|---|
Next Message | Jessica Richard | 2008-07-05 11:24:49 | How much work_mem to configure... |
Previous Message | Chris Browne | 2008-07-04 16:58:48 | Re: [QUESTION]Concurrent Access |