From: | Jeff Trout <threshar(at)torgo(dot)978(dot)org> |
---|---|
To: | Michael Stone <mstone+postgres(at)mathom(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Slow restoration question |
Date: | 2006-05-03 13:19:52 |
Message-ID: | 30D5959B-3CCD-4CB4-B2D7-30DEA9F08BB6@torgo.978.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)jefftrout(dot)com>
http://www.jefftrout.com/
http://www.stuarthamm.net/
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2006-05-03 14:16:10 | Re: Slow restoration question |
Previous Message | Jan de Visser | 2006-05-03 12:30:10 | Re: Performance Issues on Opteron Dual Core |