Re: my boss want to migrate to ORACLE - Mailing list pgsql-performance

Is it set to write back or write through?  Also, you may want to look at
lowering the stripe size.  The default on many RAID controllers is 128k,
but for PostgreSQL 8k to 32k seems a good choice.  But that's not near
as important as the cache setting being write back.

On Mon, 2004-08-02 at 15:18, Stephane Tessier wrote:
> I checked and we have a 128 megs battery backed cache on the raid
> controller...
>
> -----Original Message-----
> From: Scott Marlowe [mailto:smarlowe@qwest.net]
> Sent: 30 juillet, 2004 11:15
> To: Stephane Tessier
> Cc: markir@coretech.co.nz; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] my boss want to migrate to ORACLE
>
>
> On Fri, 2004-07-30 at 07:56, Stephane Tessier wrote:
> > I think with your help guys I'll do it!
> >
> > I'm working on it!
> >
> > I'll work on theses issues:
> >
> > we have space for more ram(we use 2 gigs on possibility of 3 gigs)
> > iowait is very high 98% --> look like postgresql wait for io access
> > raid5 -->raid0 if i'm right raid5 use 4 writes(parity,data, etc) for each
> > write on disk
>
> Just get battery backed cache on your RAID controller.  RAID0 is way too
> unreliable for a production environment.  One disk dies and all your
> data is just gone.
>
> > use more transactions (we have a lot of insert/update without
> transaction).
> > cpu look like not running very hard
> >
> > *php is not running on the same machine
> > *redhat enterprise 3.0 ES
> > *the version of postgresql is 7.3.4(using RHDB from redhat)
> > *pg_autovacuum running at 12 and 24 hour each day
> >
> >
> >
> > -----Original Message-----
> > From: pgsql-performance-owner@postgresql.org
> > [mailto:pgsql-performance-owner@postgresql.org]On Behalf Of
> > markir@coretech.co.nz
> > Sent: 29 juillet, 2004 23:00
> > To: Stephane Tessier
> > Cc: pgsql-performance@postgresql.org
> > Subject: Re: [PERFORM] my boss want to migrate to ORACLE
> >
> >
> > A furthur thought or two:
> >
> > - you are *sure* that it is Postgres that is slow? (could be Php...or your
> >   machine could be out of some resource - see next 2 points)
> > - is your machine running out of cpu or memory?
> > - is your machine seeing huge io transfers or long io waits?
> > - are you running Php on this machine as well as Postgres?
> > - what os (and what release) are you running? (guessing Linux but...)
> >
> > As an aside, they always say this but: Postgres 7.4 generally performs
> > better
> > than 7.3...so an upgrade could be worth it - *after* you have
> > solved/identified
> > the other issues.
> >
> > best wishes
> >
> > Mark
> >
> > Quoting Stephane Tessier <stephane.tessier@abovesecurity.com>:
> >
> > > Hi everyone,
> > >
> > > somebody can help me??????? my boss want to migrate to
> > > ORACLE................
> > >
> > > we have a BIG problem of performance,it's slow....
> > > we use postgres 7.3 for php security application with approximately 4
> > > millions of insertion by day and 4 millions of delete and update
> > > and archive db with 40 millions of archived stuff...
> > >
> > > we have 10 databases for our clients and a centralized database for the
> > > general stuff.
> > >
> > > database specs:
> > >
> > > double XEON 2.4 on DELL PowerEdge2650
> > > 2 gigs of RAM
> > > 5 SCSI Drive RAID 5 15rpm
> > >
> > > tasks:
> > >
> > > 4 millions of transactions by day
> > > 160 open connection 24 hours by day 7 days by week
> > > pg_autovacuum running 24/7
> > > reindex on midnight
> >
> >
> >
> > ---------------------------(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
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 8: explain analyze is your friend
> >
>
>