At Fri, 15 Jul 2005 13:45:07 -0700,
Joshua D. Drake wrote:
> Ron Wills wrote:
> > Hello all
> > 
> >   I'm running a postgres 7.4.5, on a dual 2.4Ghz Athlon, 1Gig RAM and
> > an 3Ware SATA raid. 
> 2 drives?
> 4 drives?
> 8 drives?

  3 drives raid 5. I don't believe it's the raid. I've tested this by
moving the database to the mirrors software raid where the root is
found and onto the the SATA raid. Neither relieved the IO problems.
  I was also was thinking this could be from the transactional
subsystem getting overloaded? There are several automated processes
that use the DB. Most are just selects, but the data updates and one
that updates the smaller tables that are the heavier queries. On
their own they seem to work ok, (still high IO, but fairly quick). But
if even the simplest select is called during the heavier operation,
then everything goes out through the roof. Maybe there's something I'm
missing here as well?

> RAID 1? 0? 10? 5?
> Currently the database is only 16G with about 2
> > tables with 500000+ row, one table 200000+ row and a few small
> > tables. The larger tables get updated about every two hours. The
> > problem I having with this server (which is in production) is the disk
> > IO. On the larger tables I'm getting disk IO wait averages of
> > ~70-90%. I've been tweaking the linux kernel as specified in the
> > PostgreSQL documentations and switched to the deadline
> > scheduler. Nothing seems to be fixing this. The queries are as
> > optimized as I can get them. fsync is off in an attempt to help
> > preformance still nothing. Are there any setting I should be look at
> > the could improve on this???
> > 
> > Thanks for and help in advance.
> > 
> > Ron
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: if posting/reading through Usenet, please send an appropriate
> >        subscribe-nomail command to [EMAIL PROTECTED] so that your
> >        message can get through to the mailing list cleanly
> -- 
> Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
> PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
> Managed Services, Shared and Dedicated Hosting
> Co-Authors: plPHP, plPerlNG -

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

Reply via email to