| From: | Markus Wanner <markus(at)bluegap(dot)ch> |
|---|---|
| To: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Jeffrey Baker <jwbaker(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Fusion-io ioDrive |
| Date: | 2008-07-08 09:49:36 |
| Message-ID: | 48733830.3030509@bluegap.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hi,
Jonah H. Harris wrote:
> I'm not sure how those cards work, but my guess is that the CPU will
> go 100% busy (with a near-zero I/O wait) on any sizable workload. In
> this case, the current pgbench configuration being used is quite small
> and probably won't resemble this.
I'm not sure how they work either, but why should they require more CPU
cycles than any other PCIe SAS controller?
I think they are doing a clever step by directly attaching the NAND
chips to PCIe, instead of piping all the data through SAS or (S)ATA (and
then through PCIe as well). And if the controller chip on the card isn't
absolutely bogus, that certainly has the potential to reduce latency and
improve throughput - compared to other SSDs.
Or am I missing something?
Regards
Markus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Achilleas Mantzios | 2008-07-08 12:24:46 | syslog performance when logging big statements |
| Previous Message | Jeffrey Baker | 2008-07-08 03:39:28 | Re: Practical upper limits of pgbench read/write tps with 8.3 |