Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id BA61A63240A for ; Thu, 25 Mar 2010 03:28:36 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 35158-01 for ; Thu, 25 Mar 2010 06:28:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mail.postgresql.org (Postfix) with ESMTP id DEF87632269 for ; Thu, 25 Mar 2010 03:28:25 -0300 (ADT) Received: by bwz8 with SMTP id 8so1768210bwz.3 for ; Wed, 24 Mar 2010 23:28:24 -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:message-id:subject:from:to:cc:content-type; bh=rh4xxJUiJVpyugU7AVHRMxTBR8omuw4ZxGuPsGXkJQo=; b=wqHHq/b/WHSs7kdzs0Nbb/wPwO6TyFPX4QsbQuddVT6YZHge4HXMGE9vElaYhXxY0S bHrGvcUOxJPelaOFP6Ng3IeDkJ9t3uLDWnhIST712i+vuUvJEuEgy8gIZW/WzipxsKf5 64vPX9cS1AxerK3CAJ2ZL0hBCZUeLcaGiptRo= 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; b=PYL6UHy04eiTLcEMH67w3C6BCmo3LeNYmzZPhA23qLh7QUbk2fVpqNdniJcmxRJvmL B0ySxZU9kqNbxKgO3oKxOsZxqekr48ROD7ItTuHqEZ8xYdIJM3EAb/fXght/mcSvxL6T h/lpCcgr1+DhClMq5/XCi5N6y4bxUWmeuycCU= MIME-Version: 1.0 Received: by 10.204.139.207 with SMTP id f15mr2530416bku.196.1269498504326; Wed, 24 Mar 2010 23:28:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Mar 2010 01:28:24 -0500 Message-ID: Subject: Re: memory question From: Dave Crooke To: Scott Marlowe Cc: "Campbell, Lance" , pgsql-performance@postgresql.org Content-Type: multipart/alternative; boundary=0015174c410e64aeb704829a2788 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.002 tagged_above=-10 required=5 tests=BAYES_50=0.001, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201003/315 X-Sequence-Number: 38140 --0015174c410e64aeb704829a2788 Content-Type: text/plain; charset=ISO-8859-1 What Scott said ... seconded, all of it. I'm running one 500GB database on a 64-bit, 8GB VMware virtual machine, with 2 vcores, PG 8.3.9 with shared_buffers set to 2GB, and it works great. However, it's a modest workload, most of the database is archival for data mining, and the "working set" for routine OLTP is pretty modest and easily fits in the 2GB, and it's back-ended on to a pretty decent EMC Clariion FibreChannel array. Not the typical case. For physical x86 servers, brand name (e.g. Kingston) ECC memory is down to $25 per GB in 4GB DIMMs, and $36 per GB in 8GB DIMMs .... dollars to doughnuts you have a server somewhere with 2GB or 4GB parts that can be pulled and replaced with double the density, et voila, an extra 16GB of RAM for about $500. Lots and lots of RAM is absolutely, positively a no-brainer when trying to make a DB go fast. If for no other reason than people get all starry eyed at GHz numbers, almost all computers tend to be CPU heavy and RAM light in their factory configs. I build a new little server for the house every 3-5 years, using desktop parts, and give it a mid-life upgrade with bigger drives and doubling the RAM density. Big banks running huge Oracle OLTP setups use the strategy of essentially keeping the whole thing in RAM .... HP shifts a lot of Superdome's maxed out with 2TB of RAM into this market - and that RAM costs a lot more than $25 a gig ;-) Cheers Dave --0015174c410e64aeb704829a2788 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What Scott said ... seconded, all of it.

I'm running one 500GB d= atabase on a 64-bit, 8GB VMware virtual machine, with 2 vcores, PG 8.3.9 wi= th shared_buffers set to 2GB, and it works great. However, it's a modes= t workload, most of the database is archival for data mining, and the "= ;working set" for routine OLTP is pretty modest and easily fits in the= 2GB, and it's back-ended on to a pretty decent EMC Clariion FibreChann= el array. Not the typical case.

For physical x86 servers, brand name (e.g. Kingston) ECC memory is down= to $25 per GB in 4GB DIMMs, and $36 per GB in 8GB DIMMs .... dollars to do= ughnuts you have a server somewhere with 2GB or 4GB parts that can be pulle= d and replaced with double the density, et voila, an extra 16GB of RAM for = about $500.

Lots and lots of RAM is absolutely, positively a no-brainer when trying= to make a DB go fast. If for no other reason than people get all starry ey= ed at GHz numbers, almost all computers tend to be CPU heavy and RAM light = in their factory configs. I build a new little server for the house every 3= -5 years, using desktop parts, and give it a mid-life upgrade with bigger d= rives and doubling the RAM density.

Big banks running huge Oracle OLTP setups use the strategy of essential= ly keeping the whole thing in RAM .... HP shifts a lot of Superdome's m= axed out with 2TB of RAM into this market - and that RAM costs a lot more t= han $25 a gig ;-)

Cheers
Dave



=A0
--0015174c410e64aeb704829a2788--