Re: Peformance Tuning Opterons/ Hard Disk Layout

Hi,

RAID1 (mirroring) and RAID1+0 (striping and mirroring) seems to
be a good choice. (RAID 5 is for saving money, but it doesn't have a
good performance)

I suggest you to make a different array for:
- Operating system
- db logs
- each database

It is a little bit of "wasting" disk storage, but it has the best
performance.
Forget RAID 5. If your fibre channel card and the external storage exceeds
their throughput limits you should consider to implement +1 fibre channel
and/or +1 external storage unit. (If you had such a load)

But it is only the hardware. The database structure, and the application
logic is the other 50% of the performance...

Bye
Vig Sándor

-----Original Message-----
From: pgsql-performance-owner(at)postgresql(dot)org
[mailto:pgsql-performance-owner(at)postgresql(dot)org]On Behalf Of John Allgood
Sent: Wednesday, February 23, 2005 9:42 PM
To: John Arbash Meinel
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Peformance Tuning Opterons/ Hard Disk Layout

Here is a summary about the cluster suite from redhat. All 9 databases
will be on the primary server the secondary server I have is the
failover. They don't actually share the partitions at the same time.
When you have some type of failure the backup server takes over. Once
you setup the hardware and install the clustering software. You then
setup a service "ie postgres" and then you tell it what harddrive you
will be using. /dev/sde1 and the clustering software takes care of
starting and stopping the postgres database.

Cluster Manager

The Cluster Manager feature of Red Hat Cluster Suite provides an
application failover infrastructure that can be used by a wide range of
applications, including:

* Most custom and mainstream commercial applications
* File and print serving
* Databases and database applications
* Messaging applications
* Internet and open source application

With Cluster Manager, these applications can be deployed in high
availability configurations so that they are always operational—bringing
"scale-out" capabilities to enterprise Linux deployments.

For high-volume open source applications, such as NFS, Samba, and
Apache, Cluster Manager provides a complete ready-to-use failover
solution. For most other applications, customers can create custom
failover scripts using provided templates. Red Hat Professional Services
can provide custom Cluster Manager deployment services where required.

Features

* Support for up to eight nodes: Allows high availability to be
provided for multiple applications simultaneously.
* NFS/CIFS Failover: Supports highly available file serving in Unix
and Windows environments.
* Fully shared storage subsystem: All cluster members have access to
the same storage.
* Comprehensive Data Integrity guarantees: Uses the latest I/O
barrier technology, such as programmable power switches and
watchdog timers.
* SCSI and Fibre Channel support: Cluster Manager configurations can
be deployed using latest SCSI and Fibre Channel technology.
Multi-terabyte configurations can readily be made highly available.
* Service failover: Cluster Manager not only ensures hardware
shutdowns or failures are detected and recovered from
automatically, but also will monitor your applications to ensure
they are running correctly, and will restart them automatically if
they fail.

John Arbash Meinel wrote:
> John Allgood wrote:
>
>> This some good info. The type of attached storage is a Kingston 14 bay
>> Fibre Channel Infostation. I have 14 36GB 15,000 RPM drives. I think
>> the way it is being explained that I should build a mirror with two
>> disk for the pg_xlog and the striping and mirroring the rest and put
>> all my databases into one cluster. Also I might mention that I am
>> running clustering using Redhat Clustering Suite.
>
>
> So are these 14-disks supposed to be shared across all of your 9
> databases?
> It seems to me that you have a few architectural issues here.
>
> First, you can't really have 2 masters writing to the same disk array.
> I'm not sure if Redhat Clustering gets around this. But second is that
> you can't run 2 postgres engines on the same database. Postgres doesn't
> support a clustered setup. There are too many issues with concurancy and
> keeping everyone in sync.
>
> Since you seem to be okay with having a bunch of smaller localized
> databases, which update a master database 1/day, I would think you would
> want hardware to go something like this.
>
> 1 master server, at least dual opteron with access to lots of disks
> (likely the whole 14 if you can get away with it). Put 2 as a RAID1 for
> the OS, 4 as a RAID10 for pg_xlog, and then the other 8 as RAID10 for
> the rest of the database.
>
> 8-9 other servers, these don't need to be as powerful, since they are
> local domains. Probably a 4-disk RAID10 for the OS and pg_xlog is plenty
> good, and whatever extra disks you can get for the local database.
>
> The master database holds all information for all domains, but the other
> databases only hold whatever is the local information. Every night your
> script sequences through the domain databases one-by-one, updating the
> master database, and synchronizing whatever data is necesary back to the
> local domain. I would guess that this script could actually just
> continually run, going to each local db in turn, but you may want
> nighttime only updating depending on what kind of load they have.
>
> John
> =:->
>

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.