От: Jim C. Nasby
Тема: Re: Tuning PostgreSQL
Дата: ,
Msg-id: 20030722143335.GH55392@nasby.net
(см: обсуждение, исходный текст)
Ответ на: Re: Tuning PostgreSQL  ("Alexander Priem")
Ответы: Re: Tuning PostgreSQL  ("scott.marlowe")
Список: pgsql-performance

Скрыть дерево обсуждения

Tuning PostgreSQL  ("Alexander Priem", )
 Re: Tuning PostgreSQL  ("Shridhar Daithankar", )
 Re: Tuning PostgreSQL  ("Shridhar Daithankar", )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
  Re: Tuning PostgreSQL  (Ang Chin Han, )
   Re: Tuning PostgreSQL  ("Shridhar Daithankar", )
    Re: Tuning PostgreSQL  (Ang Chin Han, )
     Re: Tuning PostgreSQL  ("Shridhar Daithankar", )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  ("Shridhar Daithankar", )
    Re: Tuning PostgreSQL  ("Alexander Priem", )
  Re: Tuning PostgreSQL  (Ron Johnson, )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  (Ron Johnson, )
   Re: Tuning PostgreSQL  (Andrew McMillan, )
    Re: Tuning PostgreSQL  ("Arjen van der Meijden", )
     Re: Tuning PostgreSQL  (Tom Lane, )
     Re: Tuning PostgreSQL  ("Balazs Wellisch", )
      Re: Tuning PostgreSQL  (Josh Berkus, )
 Re: Tuning PostgreSQL  ("Roman Fail", )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  (Josh Berkus, )
    Re: Tuning PostgreSQL  (Vincent van Leeuwen, )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  (Vincent van Leeuwen, )
    Re: Tuning PostgreSQL  (Bruno Wolff III, )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  (Andrew Sullivan, )
   Re: Tuning PostgreSQL  ("Jim C. Nasby", )
    Re: Tuning PostgreSQL  ("scott.marlowe", )
     Re: Tuning PostgreSQL  (Greg Stark, )
      Re: Tuning PostgreSQL  (Ron Johnson, )
     Re: Tuning PostgreSQL  (Vivek Khera, )
      Re: Tuning PostgreSQL  (Ron Johnson, )
       Re: Tuning PostgreSQL  ("scott.marlowe", )
        Re: Tuning PostgreSQL  (Ron Johnson, )
         Re: Tuning PostgreSQL  ("scott.marlowe", )
          Re: Tuning PostgreSQL  (Ron Johnson, )
           Re: Tuning PostgreSQL  ("scott.marlowe", )
            Re: Tuning PostgreSQL  (Ron Johnson, )
             Re: Tuning PostgreSQL, pt 2  (Ron Johnson, )
          Re: Tuning PostgreSQL  (Vivek Khera, )
      Re: Tuning PostgreSQL  (Will LaShell, )
  Re: Tuning PostgreSQL  ("Alexander Priem", )
   Re: Tuning PostgreSQL  (Ron Johnson, )
  Re: Tuning PostgreSQL  (Vivek Khera, )
 'View'-performance  ("Alexander Priem", )
  Re: 'View'-performance  (Tom Lane, )

On Tue, Jul 22, 2003 at 03:27:20PM +0200, Alexander Priem wrote:
> Wow, I never figured how many different RAID configurations one could think
> of   :)
>
> After reading lots of material, forums and of course, this mailing-list, I
> think I am going for a RAID5 configuration of 6 disks (18Gb, 15.000 rpm
> each), one of those six disks will be a 'hot spare'. I will just put the OS,
> the WAL and the data one one volume. RAID10 is way to expensive   :)
>
> If I understand correctly, this will give great read-performance, but less
> write-performance. But since this server will be equipped with an embedded
> RAID controller featuring 128Mb of battery-backed cache, I figure that this
> controller will negate that (at least somewhat). I will need to find out
> whether this cache can be configured so that it will ONLY cache WRITES, not
> READS....

I think the bigger isssue with RAID5 write performance in a database is
that it hits every spindle. The real performance bottleneck you run into
is latency, especially the latency of positioning the heads. I don't
have any proof to this theory, but I believe this is why moving WAL
and/or temp_db to seperate drives from the main database files can be a
big benefit for some applications; not because of disk bandwidth but
because it drastically cuts down the amount of time the heads have to
spend flying around the disk.

Of course, this is also highly dependant on how the filesystem operates,
too. If it puts your WALs, temp_db, and database files very close to
each other on the drive, splitting them out to seperate spindles won't
help as much.
--
Jim C. Nasby, Database Consultant                  
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


В списке pgsql-performance по дате сообщения:

От: Jord Tanner
Дата:
Сообщение: Re: Dual Xeon + HW RAID question
От: "Castle, Lindsay"
Дата:
Сообщение: One table or many tables for data set