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
|
Список | 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 по дате отправления: