Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 69E9A64FE45 for ; Tue, 14 Oct 2008 22:38:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 88720-04 for ; Tue, 14 Oct 2008 22:38:45 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by postgresql.org (Postfix) with ESMTP id CF72E64FE49 for ; Tue, 14 Oct 2008 22:38:45 -0300 (ADT) Received: by nf-out-0910.google.com with SMTP id c7so1146074nfi.23 for ; Tue, 14 Oct 2008 18:38:43 -0700 (PDT) Received: by 10.210.117.1 with SMTP id p1mr405799ebc.40.1224034723367; Tue, 14 Oct 2008 18:38:43 -0700 (PDT) Received: from oxford.xeocode.com.enterprisedb.com ([87.127.95.198]) by mx.google.com with ESMTPS id t12sm111337gvd.10.2008.10.14.18.38.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Oct 2008 18:38:42 -0700 (PDT) To: Greg Smith Cc: Kevin Murphy , pgsql-general@postgresql.org Subject: Re: Drupal and PostgreSQL - performance issues? In-Reply-To: (Greg Smith's message of "Tue\, 14 Oct 2008 18\:23\:09 -0400 \(EDT\)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:PG" 91497) References: <2434A118-CEFA-43A9-BA88-006EC1F80326@hoegh.org> <200810122214.53558.uwe@oss4u.com> <20081013090228.248a665f@dawn.webthatworks.it> <20081014114011.0ebe495a@dawn.webthatworks.it> <3250B5B6-B507-4E79-BAF0-E98B73E9FED9@hoegh.org> <48F4B3C2.1050805@genome.chop.edu> From: Gregory Stark Organization: EnterpriseDB Date: Wed, 15 Oct 2008 02:38:40 +0100 Message-ID: <87od1mbpsv.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200810/589 X-Sequence-Number: 138838 Greg Smith 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!