Re: Performance tuning on RedHat Enterprise Linux 3 - Mailing list pgsql-general

From P.J. \"Josh\" Rovero
Subject Re: Performance tuning on RedHat Enterprise Linux 3
Date
Msg-id 41B5A724.7070907@sonalysts.com
Whole thread Raw
In response to Re: Performance tuning on RedHat Enterprise Linux 3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Performance tuning on RedHat Enterprise Linux 3  (Tony Wasson <ajwasson@gmail.com>)
List 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@sonalysts.com    www.sonalysts.com    215 Parkway North
Work: (860)326-3671 or 442-4355                     Waterford CT 06385
***********************************************************************


pgsql-general by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Index scan vs. Seq scan on timestamps
Next
From: Frank van Vugt
Date:
Subject: RC1, missing -lpthread when building with --disable-shared on i686