Skip site navigation (1) Skip section navigation (2)

Re: Hardware/OS recommendations for large databases (

From: Alan Stange <stange(at)rentec(dot)com>
To: Luke Lonergan <llonergan(at)greenplum(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Dave Cramer <pg(at)fastcrypt(dot)com>, Joshua Marsh <icub3d(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Hardware/OS recommendations for large databases (
Date: 2005-11-20 04:43:28
Message-ID: 437FFEF0.9090409@rentec.com (view raw or flat)
Thread:
Lists: pgsql-performance
Another data point. 

We had some down time on our system today to complete some maintenance 
work.  It took the opportunity to rebuild the 700GB file system using 
XFS instead of Reiser.

One iostat output for 30 seconds is

avg-cpu:  %user   %nice    %sys %iowait   %idle
           1.58    0.00   19.69   31.94   46.78

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sdd             343.73    175035.73       277.55    5251072       8326

while doing a select count(1) on the same large table as before.   
Subsequent iostat output all showed that this data rate was being 
maintained.  The system is otherwise mostly idle during this measurement.

The sequential read rate is 175MB/s.  The system is the same as earlier, 
one cpu is idle and the second is ~40% busy doing the scan and ~60% 
idle.   This is  postgresql 8.1rc1, 32KB block size.  No tuning except 
for using a 1024KB read ahead.

The peak speed of the attached storage is 200MB/s (a 2Gb/s fiber channel 
controller).  I see no reason why this configuration wouldn't generate 
higher IO rates if a faster IO connection were available.

Can you explain again why you think there's an IO ceiling of 120MB/s 
because I really don't understand?

-- Alan



In response to

Responses

pgsql-performance by date

Next:From: Mark KirkwoodDate: 2005-11-20 08:55:59
Subject: Re: Hardware/OS recommendations for large databases (
Previous:From: Alan StangeDate: 2005-11-20 02:43:48
Subject: Re: Hardware/OS recommendations for large databases (

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group