From: Gregory Stark <stark@enterprisedb.com>
To: Greg Smith <gsmith@gregsmith.com>
Cc: Kevin Murphy <murphy@genome.chop.edu>
Cc: pgsql-general@postgresql.org
Subject: Re: Drupal and PostgreSQL - performance issues?
Date: Wed, 15 Oct 2008 02:38:40 +0100
Message-ID: <87od1mbpsv.fsf@oxford.xeocode.com> (raw)
In-Reply-To: <Pine.GSO.4.64.0810141747240.5472@westnet.com>
References: <2434A118-CEFA-43A9-BA88-006EC1F80326@hoegh.org>
<200810122214.53558.uwe@oss4u.com>
<20081013090228.248a665f@dawn.webthatworks.it>
<e7e0a2570810131945x1bbf10b8r67c0ac2a340b436f@mail.gmail.com>
<20081014114011.0ebe495a@dawn.webthatworks.it>
<3250B5B6-B507-4E79-BAF0-E98B73E9FED9@hoegh.org>
<Pine.GSO.4.64.0810140942010.28645@westnet.com>
<48F4B3C2.1050805@genome.chop.edu>
<Pine.GSO.4.64.0810141747240.5472@westnet.com>
Greg Smith <gsmith@gregsmith.com> writes:
> DB2 has automatically updated the "shmmax" kernel
> parameter from "33554432" to the recommended value "268435456".
This seems like a bogus thing for an application to do though. The Redhat
people seem happy with the idea but I'm pretty sure it would violate several
Debian packaging rules. Generally it seems crazy for a distribution to ship
configured one way by default but have packages change that behind the user's
back. What if the admin set SHMMAX that way because he wanted it? What happens
when a new distribution package has a new default but doesn't adjust it
because it sees the "admin" has changed it -- even though it was actually
Postgres which made the change?
> And you're off--it bumped that from the default 32MB to 256MB. The problem for
> PostgreSQL is that nobody who is motivated enough to write such magic for a
> large chunk of the supported platforms has had the time to do it yet. I'll get
> to that myself eventually even if nobody else does, as this is a recurring
> problem I'd like to make go away.
ISTM the right way to make it go away is to allocate temporary files and mmap
them instead of using sysv shared memory. Then we can mmap as much as we want.
Before we lose root privileges we can even mlock as much as we want.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: stark@enterprisedb.com, gsmith@gregsmith.com, murphy@genome.chop.edu, pgsql-general@postgresql.org
Subject: Re: Drupal and PostgreSQL - performance issues?
In-Reply-To: <87od1mbpsv.fsf@oxford.xeocode.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox