X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 1B1C7DBAA1 for ; Sun, 20 Nov 2005 00:44:48 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 65216-02 for ; Sun, 20 Nov 2005 04:44:46 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from unicorn.rentec.com (unicorn.rentec.com [216.223.240.9]) by svr1.postgresql.org (Postfix) with ESMTP id 7A87BDB9EB for ; Sun, 20 Nov 2005 00:44:45 -0400 (AST) Received: from ram.rentec.com (mailhost [192.5.35.66]) by unicorn.rentec.com (8.13.1/8.12.1) with ESMTP id jAK4iRR6019192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Nov 2005 23:44:28 -0500 (EST) X-Source: non-mednet Received: from [172.16.160.106] (stangesun.rentec.com [172.16.160.106]) by ram.rentec.com (8.13.1/8.12.1) with ESMTP id jAK4huxL014736; Sat, 19 Nov 2005 23:43:56 -0500 (EST) Message-ID: <437FFEF0.9090409@rentec.com> Date: Sat, 19 Nov 2005 23:43:28 -0500 From: Alan Stange User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Luke Lonergan CC: Greg Stark , Dave Cramer , Joshua Marsh , pgsql-performance@postgresql.org Subject: Re: Hardware/OS recommendations for large databases ( References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Logged: Logged by unicorn.rentec.com as jAK4iRR6019192 at Sat Nov 19 23:44:28 2005 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.013 required=5 tests=[AWL=0.013] X-Spam-Score: 0.013 X-Spam-Level: X-Archive-Number: 200511/406 X-Sequence-Number: 15663 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