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: | Whole Thread | Raw Message | 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-----
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 |