From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Rajesh Kumar Mallah <mallah(dot)rajesh(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: 10GbE / iSCSI storage for postgresql. |
Date: | 2011-09-22 04:14:18 |
Message-ID: | 4E7AB61A.70804@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 09/22/2011 03:49 AM, Rajesh Kumar Mallah wrote:
> Hi ,
>
> Can PostgreSQL run fast ( within 80% of DAS) with iSCSI sotrage
> connected via 10GbE ?
"Maybe".
What's that 80% of? Sequential read throughput? Random IOPS? Individual
read latency?
What's the expected workload? Read-heavy, write-heavy, or middle-ground?
Data warehouse/OLAP or OLTP? Lots of small simple transactions, or fewer
big complex transactions?
Does the system on the other end of the iSCSI link have battery-backed
write caching, flash-logged write cache, or some other way to guarantee
writes are persistent without having to wait for data to flush out to
spinning disks? You'll need something like this for decent write
performance especially if you're doing lots of small transactions. If
the SAN doesn't have a safe way to cache writes you can partly work
around the issue by doing fewer bigger transactions and/or by using a
commit_delay.
What kind of read cache does the SAN have? How much contention with
other users will there be? How big is its write-back cache (if it has
one)? Does it have any kind of QoS to prevent something like someone
disk-imaging a server from starving your Pg instance of read bandwidth?
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2011-09-22 04:19:30 | Re: create extension failed |
Previous Message | Scott Marlowe | 2011-09-22 01:56:00 | Re: Materialized views in Oracle |