Re: Slow restoration question - Mailing list pgsql-performance

From Jeff Trout
Subject Re: Slow restoration question
Date
Msg-id 30D5959B-3CCD-4CB4-B2D7-30DEA9F08BB6@torgo.978.org
Whole thread Raw
In response to Re: Slow restoration question  (Michael Stone <mstone+postgres@mathom.us>)
Responses Re: Slow restoration question
Re: Slow restoration question
List pgsql-performance
On May 3, 2006, at 8:18 AM, Michael Stone wrote:

> On Tue, May 02, 2006 at 08:09:52PM -0600, Brendan Duddridge wrote:
>>               -------Sequential Output-------- ---Sequential
>> Input--  --Random--
>>               -Per Char- --Block--- -Rewrite-- -Per Char- --
>> Block---  --Seeks---
>> Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %
>> CPU  /sec %CPU
>>             0 40365 99.4 211625 61.4 212425 57.0 50740 99.9
>> 730515  100.0 45897.9 190.1
> [snip]
>> Do these numbers seem decent enough for a Postgres database?
>
> These numbers seem completely bogus, probably because bonnie is
> using a file size smaller than memory and is reporting caching
> effects. (730MB/s isn't possible for a single external RAID unit
> with a pair of 2Gb/s interfaces.) bonnie in general isn't
> particularly useful on modern large-ram systems, in my experience.
>

Bonnie++ is able to use very large datasets. It also tries to figure
out hte size you want (2x ram) - the original bonnie is limited to 2GB.

--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/



pgsql-performance by date:

Previous
From: Jan de Visser
Date:
Subject: Re: Performance Issues on Opteron Dual Core
Next
From: Vivek Khera
Date:
Subject: Re: Slow restoration question