Обсуждение: Ideal Disk recommendation for PostgreSQL

In response to Bhaskar Sirohi :
> Hi All,
>
> We are right now in initial phase to setup a production server having
> PostgreSQL database installed and would require help with Disk configuration.
> The database size would grow approx to 500 GB. I have gone through the
> following link http://momjian.us/main/writings/pgsql/hw_performance/index.html
> which was very helpful.  However what I would like to understand is, do you
> have any figures around minimum / optimal disk performance for postgresql to
> operate? As an example I remember MS have a document on Exchange that gives

Not really. If you have enough money, you can divide your disk-space
into 2 or 3 parts (separate disks and controllers) for data, indexes and
WAL-logging, using tablespaces. But all depends on your workload (and
the available money ...)


Regards, Andreas
--
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431  2EB0 389D 1DC2 3172 0C99

On Tue, Jun 15, 2010 at 1:48 PM, Bhaskar Sirohi
<bhaskar.sirohi@druvaa.com> wrote:
> Hi All,
>
> We are right now in initial phase to setup a production server having
> PostgreSQL database installed and would require help with Disk
> configuration. The database size would grow approx to 500 GB. I have gone
> through the following link
> http://momjian.us/main/writings/pgsql/hw_performance/index.html which was
> very helpful.  However what I would like to understand is, do you have any
> figures around minimum / optimal disk performance for postgresql to operate?
> As an example I remember MS have a document on Exchange that gives some
> rough guidance around the number of IOPS it needs depending on number of
> users / mailbox size.

Whether you need fast sequential throughput or fast random access, the
best setup is usually to throw lots of drives at the problem.  If you
need multiple volumes to get lots of drives then use tablespaces to
move busy tables to less busy drive sets.  If you need lots of writes
to happen all the time, then using a battery backed caching RAID
controller or two or 8 is a necessity.

So, IOPS is important for transactional stuff, but for report
generation and things that tend to seq scan, throughput is more
important.  You tend to get good numbers either way with fast caching
RAID controllers RAID-10.  sometimes you can use software RAID and
lots of disks for report servers with good results, but if the write
load even blips up (like when loading data) they can slow to a crawl
real fast.  Note that software RAID can benefit greatly from a
hardware caching controller in JBOD (just a bunch of disks) mode and
offloads some small amount of work from the RAID controller to a cpu.

So, what are you doing with your DB, model wise?