От: Andrew McMillan
Тема: Re: Tuning PostgreSQL
Дата: ,
Msg-id: 1059129938.6896.1109.camel@kant.mcmillan.net.nz
(см: обсуждение, исходный текст)
Ответ на: Re: Tuning PostgreSQL  ("Alexander Priem")
Ответы: Re: Tuning PostgreSQL  ("Arjen van der Meijden")
Список: 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 Wed, 2003-07-23 at 00:53, 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   :)

The general heuristic is that RAID-5 is not the way to deal with
databases.  Now surely someone will disagree with me, but as I
understand it RAID-5 has a bottleneck on a single disk for the
(checksum) information.  Bottleneck is not the word you want to hear in
the context of "database server".

RAID-1 (mirroring) or RAID-10 (sort-of-mirrored-RAID-5) is the best
choice.

As far as FS performance goes, a year or two ago I remember someone
doing an evaluation of FS performance for PostgreSQL and they found that
the best performance was...

FAT

Yep: FAT

The reason is that a lot of what the database is doing, especially
guaranteeing writes (WAL) and so forth is best handled through a
filesystem that does not get in the way.  The fundamentals will not have
changed.

It is for this reason that ext2 is very much likely to be better than
ext3.  XFS is possibly (maybe, perhaps) OK, because there are
optimisations in there for databases, but the best optimisation is to
not be there at all.  That's why Oracle want direct IO to disk
partitions so they can implement their own "filesystem" (i.e. record
system... table system...) on a raw partition.

Personally I don't plan to reboot my DB server more than once a year (if
that (even my_laptop currently has 37 days uptime, not including
suspend).  On our DB servers I use ext2 (rather than ext3) mounted with
noatime, and I bite the 15 minutes to fsck (once a year) rather than
screw general performance with journalling database on top of
journalling FS.  I split pg_xlog onto a separate physical disk, if
performance requirements are extreme.

Catalyst's last significant project was to write the Domain Name
registration system for .nz (using PostgreSQL).  Currently we are
developing the electoral roll for the same country (2.8 million electors
living at 1.4 million addresses).  We use Oracle (or Progress, or MySQL)
if a client demands them, but we use PostgreSQL if we get to choose.
Increasingly we get to choose.  Good.

Regards,
                    Andrew.
--
---------------------------------------------------------------------
Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St,  Wellington
WEB: http://catalyst.net.nz/         PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201     MOB: +64(21)635-694    OFFICE: +64(4)499-2267
           Survey for nothing with http://survey.net.nz/
---------------------------------------------------------------------



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

От: Tom Lane
Дата:
Сообщение: Re: Tuning PostgreSQL
От: "Balazs Wellisch"
Дата:
Сообщение: Re: Tuning PostgreSQL