Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id AAC5D63302F for ; Wed, 24 Mar 2010 23:06:24 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 01483-03 for ; Thu, 25 Mar 2010 02:06:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-gy0-f174.google.com (mail-gy0-f174.google.com [209.85.160.174]) by mail.postgresql.org (Postfix) with ESMTP id D453A632CB7 for ; Wed, 24 Mar 2010 23:06:12 -0300 (ADT) Received: by gyg8 with SMTP id 8so3944618gyg.19 for ; Wed, 24 Mar 2010 19:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9lFUWWjWwaI4Snfz7UsP7L+MDUxpB6TUPGp/1HhJYk8=; b=yD2IWBstJhDr0qWPlbRYyFAgDgqPk3AzTmkF09wMHBJZduUpm8S6ztiT28xIMbfnsF ixwOZGat/Nm1Ny54Pnh3YlhHV3vFVk5OaVXP1tX7tr1wXiBZSrhC5wggmz8ZeEVPzOmK aqibWM4uhJw3jgJGP+04HKY7K3TWcSWxgzrUo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cLsjO80KUguFq42lAGzHigHi9vSAqyYnIME+XuSKzUtLZHVa3RRMdySQmcrl+uV4/B AHFgo707HplzrtEzxf5ByAeGD6b+LN8kHPmUlUX3HTbMdHuer89K/OtDZLYBNwqaHOnU msJCDRbNNInrWHZvdoHiSGiXZyb+J7TEuKLVI= MIME-Version: 1.0 Received: by 10.151.14.14 with HTTP; Wed, 24 Mar 2010 19:06:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Mar 2010 20:06:10 -0600 Received: by 10.150.235.15 with SMTP id i15mr546098ybh.80.1269482770932; Wed, 24 Mar 2010 19:06:10 -0700 (PDT) Message-ID: Subject: Re: memory question From: Scott Marlowe To: "Campbell, Lance" Cc: pgsql-performance@postgresql.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.474 tagged_above=-10 required=5 tests=AWL=0.125, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/313 X-Sequence-Number: 38138 On Wed, Mar 24, 2010 at 6:49 PM, Campbell, Lance wrote= : > PostgreSQL 8.4.3 > > Linux Redhat 5.0 > > Question: How much memory do I really need? The answer is "as much as needed to hold your entire database in memory and a few gig left over for sorts and backends to play in." > From my understanding there are two primary strategies for setting up > PostgreSQL in relationship to memory: > > > > 1)=A0=A0=A0=A0=A0 Rely on Linux to cache the files.=A0 In this approach y= ou set the > shared_buffers to a relatively low number. > > 2)=A0=A0=A0=A0=A0 You can set shared_buffers to a very large percentage o= f your memory > so that PostgreSQL reserves the memory for the database. The kernel is better at caching large amounts of memory. Pg is better at handling somewhat smaller amounts and not flushing out random access data for sequential access data. > I am currently using option #1.=A0 I have 24 Gig of memory on my server a= nd > the database takes up 17 Gig of disk space.=A0 When I do the Linux comman= d > =93top=94 I notice that 19 Gig is allocated for cache.=A0 Is there a way = for me to > tell how much of that cache is associated with the caching of database > files? Probably nearly all of that 19G for cache is allocated for pg files. Not sure how to tell off the top of my head though. > I am basically asking how much memory do I really need?=A0 Maybe I have > complete over kill.=A0 Maybe I am getting to a point where I might need m= ore > memory. Actually, there are three levels of caching that are possible. 1: Entire db, tables and indexes, can fit in RAM. This is the fastest method. Worth the extra $ for RAM if you can afford it / db isn't too huge. 2: Indexes can fit in RAM, some of tables can. Still pretty fast. Definitely worth paying a little extra for. 3: Neither indexes nor tables can wholly fit in RAM. At this point the speed of your large disk array becomes important, and you want a fast cachine RAID controller. Both of these items (disk array and RAID controller) are considerably more costly than 16 or 32 Gigs of RAM. > My thought was I could use option #2 and then set the number to a lower > amount.=A0 If the performance is bad then slowly work the number up. I'm not sure what you mean. Install less RAM and let PG do all the caching? Usually a bad idea. Usually. I'm sure there are use cases that it might be a good idea on. But keep in mind, a large amount of shared_buffers doesn't JUST buffer your reads, it also results in a much large memory space to keep track of in terms of things that need to get written out etc. I'm actually about to reduce the shared_buffers from 8G on one reporting server down to 1 or 2G cause that's plenty, and it's having a hard time keeping up with the huge checkpoints it's having to do. > Our server manager seems to think that I have way to much memory.=A0 He t= hinks > that we only need 5 Gig. How much do you absolutely need to boot up, run postgresql, and not run out of memory? That's what you "need" and it's probably around 1Gig. It's just no less arbitraty than 5G. Did he show you how he arrived at this number? If your DB is 17Gig on disk, it's foolish to be cheap on memory. > I don=92t really believe that.=A0 But I want to cover > myself.=A0 With money tight I don=92t want to be the person who is wastin= g > resources.=A0 We need to replace our database servers so I want to do the > right thing. You can waste your time (valuable but sunk cost) other people's time (more valuable, also sunk cost) or "waste" a few dollars on memory. 24Gig isn't that expensive really compared to say 10 seconds per transaction for 100 users, 1000 times a day. Or 11 user days in a single day. 10s of seconds start to add up.