Re: Slow restoration question

Поиск
Список
Период
Сортировка
От Jeff Trout
Тема Re: Slow restoration question
Дата
Msg-id 30D5959B-3CCD-4CB4-B2D7-30DEA9F08BB6@torgo.978.org
обсуждение исходный текст
Ответ на Re: Slow restoration question  (Michael Stone <mstone+postgres@mathom.us>)
Ответы Re: Slow restoration question  (Vivek Khera <vivek@khera.org>)
Re: Slow restoration question  (Michael Stone <mstone+postgres@mathom.us>)
Список 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 по дате отправления:

Предыдущее
От: Jan de Visser
Дата:
Сообщение: Re: Performance Issues on Opteron Dual Core
Следующее
От: Vivek Khera
Дата:
Сообщение: Re: Slow restoration question