From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martin Foster <martin(at)ethereal-realms(dot)org> |
Cc: | Richard Huxton <dev(at)archonet(dot)com>, PostgreSQL Novice <pgsql-novice(at)postgresql(dot)org>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: [PERFORM] Extreme high load averages |
Date: | 2003-07-06 15:19:25 |
Message-ID: | 9918.1057504765@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice pgsql-performance |
Martin Foster <martin(at)ethereal-realms(dot)org> writes:
>> The only time that I have ever seen load averages of 30 or more under
>> OpenBSD is when one of my scripts goes wild.
Note also that "high load average" is not per se an indication that
anything is wrong. In Postgres, if you have thirty queries waiting
for disk I/O, that's thirty processes --- so if that's the average
state then the kernel will report a load average of thirty. While
I'm no MySQL expert, I believe that the equivalent condition in MySQL
would be thirty threads blocked for I/O within one process. Depending
on how your kernel is written, that might show as a load average of
one ... but the difference is completely illusory, because what counts
is the number of disk I/Os in flight, and that's the same.
You didn't say whether you were seeing any real performance problems,
like slow queries or performance dropping when query load rises, but
that is the aspect to concentrate on.
I concur with the nearby recommendations to drop your resource settings.
The thing you have to keep in mind about Postgres is that it likes to
have a lot of physical RAM available for kernel disk buffers (disk
cache). In a correctly tuned system that's been up for any length of
time, "free memory" should be nearly nada, and the amount of RAM used
for disk buffers should be sizable (50% or more of RAM would be good
IMHO).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Boget, Chris | 2003-07-06 15:46:57 | Re: Replace into... |
Previous Message | Nabil Sayegh | 2003-07-06 11:43:53 | Re: Replace into... |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-07-06 15:25:28 | Re: Another POC initdb patch |
Previous Message | Shridhar Daithankar | 2003-07-06 14:10:32 | Another POC initdb patch |