Re: URGENT: Performance tuning - Mailing list pgsql-general

From Peter Dimov
Subject Re: URGENT: Performance tuning
Date
Msg-id 20020623062434.79570.qmail@web21509.mail.yahoo.com
Whole thread Raw
In response to Re: URGENT: Performance tuning  (Curt Sampson <cjs@cynic.net>)
List pgsql-general

Disk can be the problem.

All the system have the same disk type. It was WD 40 GB , IDE 7200.

I calculate the memory so, that all the date to be cached and so to get better performance.

My idea was, that in production we can install the needed RAM - 3 - 4 GB, so we will cache the data -

realy only for selects.

 

The CPU usage is 100 on P II one processor system and 50% on Athlon DUAL system, but for athlon

it is ok because the postgres can start the task on only one from this ( or I am wrong?).

 

I will change the disks to SCSI and will check the result.

Suppresed was that oracle ran on the same system and was so much faster.

 

thanks and regards.

  Curt Sampson <cjs@cynic.net> wrote:

On Sat, 22 Jun 2002, Peter Dimov wrote:

> First I tested with P II 400 MHz 256 MB RAM.
> And second Dual Athlon MP , 1.6 GHz , 1 or 2 GB RAM.
> I expected to get big advantage from the second system and
> was very supprise from the results : I wan only 30 - 40% faster as the first.

Well, did you analyze your load carefully? How much of your
application is CPU-bound, and how much is disk I/O bound? How much
memory do you need to cache the working set, if it can be cached
at all?

Disks are often very important for database work, far more so than
CPU or memory. I have an application with queries that run about
the same on a 600 MHz Pentium III and a dual 2 GHz Xeon system, if
you use the same disks.

> I think the mistake is by tuning....

Very likely.

cjs
--
Curt Sampson +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC



Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup

pgsql-general by date:

Previous
From: Curt Sampson
Date:
Subject: Re: URGENT: Performance tuning
Next
From: Oskar Berggren
Date:
Subject: Re: SQL server application porting headache