Re: Extreme high load averages

От: Martin Foster
Тема: Re: Extreme high load averages
Дата: ,
Msg-id: 3F088680.5070109@ethereal-realms.org
(см: обсуждение, исходный текст)
Ответ на: Re: Extreme high load averages  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

Extreme high load averages  (Martin Foster, )
 Re: Extreme high load averages  (Richard Huxton, )
  Re: Extreme high load averages  (Martin Foster, )
   Re: Extreme high load averages  (Tom Lane, )
    Re: Extreme high load averages  (Martin Foster, )
  Re: Extreme high load averages  (Martin Foster, )
   Re: Extreme high load averages  (Dennis Björklund, )
    Re: [NOVICE] Extreme high load averages  (Martin Foster, )
     Re: [NOVICE] Extreme high load averages  ("Shridhar Daithankar", )
      Re: [NOVICE] Extreme high load averages  (Martin Foster, )
       Re: [NOVICE] Extreme high load averages  ("Shridhar Daithankar", )
        Re: [NOVICE] Extreme high load averages  (Martin Foster, )
        Re: [NOVICE] Extreme high load averages  (Martin Foster, )
     Re: [NOVICE] Extreme high load averages  (Sean Chittenden, )
 Re: Extreme high load averages  ("Shridhar Daithankar", )
  Re: Extreme high load averages  (Martin Foster, )
   Re: Extreme high load averages  (Shridhar Daithankar, )
    Re: Extreme high load averages  (Martin Foster, )
     Re: Extreme high load averages  ("scott.marlowe", )
      Re: Extreme high load averages  (Martin Foster, )
      Re: Extreme high load averages  ("Matthew Nuzum", )
       Re: Extreme high load averages  ("scott.marlowe", )

Tom Lane wrote:

> Martin Foster <> 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

Under a circumstance where we have 250 concurrent users, MySQL would
report an uptime of 0.5 sometimes 0.8 depending on the tasks being
performed.

This would translate to wait times averaging less then a second, and
under a heavy resource script 4 seconds.    That system had less RAM
however.

This new system when showing a load average of 30, produced wait times
of 12 seconds averages and about 30 seconds for the heavy resource
script.     The web server itself showed a load average of 0.5 showing
that it was not heavy client interaction slowing things down.

So there is a very noticeable loss of performance when the system
skyrockets like that.   All of the load as indicated by top is at user
level, and not swap is even touched.

This may help show why I was slightly concerned.

    Martin Foster
    Creator/Designer Ethereal Realms
    




В списке pgsql-performance по дате сообщения:

От: "Matthew Nuzum"
Дата:
Сообщение: Re: Moving postgresql.conf tunables into 2003...
От: "Matthew Nuzum"
Дата:
Сообщение: Re: Moving postgresql.conf tunables into 2003...