Re: Performance tuning on RedHat Enterprise Linux 3

From: "P(dot)J(dot) \"Josh\" Rovero" <rovero(at)sonalysts(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Paul Tillotson <pntil(at)shentel(dot)net>, David Esposito <pgsql-general(at)esposito(dot)newnetco(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Performance tuning on RedHat Enterprise Linux 3
Date: 2004-12-07 12:50:44
Message-ID: 41B5A724.7070907@sonalysts.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

There are many reports of kernel problems with memory allocation
(too agressive) and swap issues with RHEL 3.0 on both RAID
and non-RAID systems. I hope folks have worked through all
those issues before blaming postgresql.

Tom Lane wrote:

>
> If I thought that a 200% error in memory usage were cause for a Chinese
> fire drill, then I'd say "yeah, let's do that". The problem is that the
> place where performance actually goes into the toilet is normally an
> order of magnitude or two above the nominal sort_mem setting (for
> obvious reasons: admins can't afford to push the envelope on sort_mem
> because of the various unpredictable multiples that may apply). So
> switching to a hugely more expensive implementation as soon as we exceed
> some arbitrary limit is likely to be a net loss not a win.
>
> If you can think of a spill methodology that has a gentle degradation
> curve, then I'm all for that. But I doubt there are any quick-hack
> improvements to be had here.
>
> regards, tom lane

--
P. J. "Josh" Rovero Sonalysts, Inc.
Email: rovero(at)sonalysts(dot)com www.sonalysts.com 215 Parkway North
Work: (860)326-3671 or 442-4355 Waterford CT 06385
***********************************************************************

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Frank van Vugt 2004-12-07 13:35:34 RC1, missing -lpthread when building with --disable-shared on i686
Previous Message Stephan Szabo 2004-12-07 12:26:37 Re: Index scan vs. Seq scan on timestamps