Re: The black art of postgresql.conf tweaking

From: Gaetano Mendola <mendola(at)bigfoot(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Paul Serby <paul(dot)serby(at)clockltd(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: The black art of postgresql.conf tweaking
Date: 2004-08-06 18:27:01
Message-ID: 4113CD75.2060508@bigfoot.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Josh Berkus wrote:

| Paul,
|
|
|>>Physical Memory: 2077264 kB
|
|
|>>sort_mem = 12000
|
|
| Hmmm. Someone may already have mentioned this, but that looks problematic.
| You're allowing up to 12MB per sort, and up to 300 connections. Even if each
| concurrent connection averages only one sort (and they can use more) that's
| 3600MB ... roughly 1.5 times your *total* RAM, leaving out RAM for Apache,
| postmaster, shared buffers, etc.
|
| I strongly suggest that you either decrease your total connections or your
| sort_mem, or both.

Of course your are speaking about the "worst case", I aplly in scenarios like
this on the rule 80/20: 80% of connection will perform a sort and 20% will allocate
memory for the sort operation in the same window time:

300 -- 80% --> 240 --> 20% --> 48

48 * 12MB = 576 MB

that seems resonable with the total ammount of memory available.

Am I too optimistic?

Regards
Gaetano Mendola

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBE81z7UpzwH2SGd4RAuzzAJ98Ze0HQedKaZ/laT7P1OS44FG0CwCfaWkY
MAR1TEY1+x61PoXjK/K8Q4Y=
=8UmF
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Martin Foster 2004-08-06 22:58:31 Re: Performance Bottleneck
Previous Message Mike Benoit 2004-08-06 17:06:51 Re: Performance Bottleneck