From owner-freebsd-stable Thu Jul 11 8: 9:25 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5939637B400 for ; Thu, 11 Jul 2002 08:09:21 -0700 (PDT) Received: from yertle.kciLink.com (yertle.kcilink.com [216.194.193.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD18943E52 for ; Thu, 11 Jul 2002 08:09:20 -0700 (PDT) (envelope-from khera@kciLink.com) Received: from onceler.kciLink.com (onceler.kciLink.com [216.194.193.106]) by yertle.kciLink.com (Postfix) with ESMTP id 536D42178D; Thu, 11 Jul 2002 11:09:15 -0400 (EDT) Received: by onceler.kciLink.com (Postfix, from userid 100) id 033543D07; Thu, 11 Jul 2002 11:09:14 -0400 (EDT) From: Vivek Khera MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15661.40858.819829.49331@onceler.kciLink.com> Date: Thu, 11 Jul 2002 11:09:14 -0400 To: Curt Sampson Cc: stable@freebsd.org, Subject: Re: [GENERAL] was there a change in FreeBSD SHM implementation from 4.4 to 4.6? (postgres trouble) In-Reply-To: References: <15660.31149.224797.969563@onceler.kciLink.com> X-Mailer: VM 7.04 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>>>> "CS" == Curt Sampson writes: >> For those familiar with postgres, I was using shared_buffers=100000 >> with 4.4, but had to back that down to 32000 for 4.6. This is >> obviously impacting performance... CS> Yes, I'm sure your performance improved. By going from 780 MB to CS> 25 MB of shared memory, you just increased the amount of data the CS> OS can buffer from about 1.1 GB to 1.8 GB. You've just increased CS> your cache size by about 60%. Actually performance went down. Way down. I disagree with your argument that increasing the cache will help, since the cache is not needed if you don't pushd out your SHM pages in the first place and need to reload them quickly. What it turned out to be was that SHMMAX was larger than my SHMALL. Why the kernel let me build it that way without warnings is a hole in the config system, but not fatal. Bumping up SHMALL fixed my issue, and now my performance is back to normal. Perhaps Postgres could identify the smaller of SHMMAX and SHMALL when reporting the failure to get the memory, and indicate which one is too small. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message