Re: [Testperf-general] dbt2 & opteron performance

Поиск
Список
Период
Сортировка
От Mark Wong
Тема Re: [Testperf-general] dbt2 & opteron performance
Дата
Msg-id 200507292011.j6TKB0jA007908@smtp.osdl.org
обсуждение исходный текст
Ответ на Re: [Testperf-general] dbt2 & opteron performance  ("Jim C. Nasby" <decibel@decibel.org>)
Ответы Re: [Testperf-general] dbt2 & opteron performance  ("Jim C. Nasby" <decibel@decibel.org>)
Список pgsql-hackers
On Fri, 29 Jul 2005 14:57:42 -0500
"Jim C. Nasby" <decibel@decibel.org> wrote:

> On Fri, Jul 29, 2005 at 12:51:57PM -0700, Mark Wong wrote:
> > > Not sure I fully understand what you're trying to say, but it seems like
> > > it might still be worth trying my original idea of just turning all 80
> > > disks into one giant RAID0/striped array and see how much more bandwidth
> > > you get out of that. At a minimum it would allow you to utilize the
> > > remaining spindles, which appear to be unused right now.
> > 
> > I have done that before actually, when the tablespace patch came out.  I
> > was able to get almost 40% more throughput with half the drives than
> > striping all the disks together.
> 
> Wow, that's a pretty stunning difference... any idea why?
> 
> I think it might be very useful to see some raw disk IO benchmarks...

A lot of it has to do with how the disk is being accessed.  The log is
ideally doing sequential writes, some tables only read, some
read/writer.  The varying access patterns between tables/log/indexes can
negatively conflict with each other.

Some of it has to do with how the OS deals with file systems.  I think
on linux is there a page buffer flush daemon per file system.  A real OS
person can answer this part better than me.

Mark


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: [Testperf-general] dbt2 & opteron performance
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: [Testperf-general] dbt2 & opteron performance