Message-ID: <4C48F6E1.6020004@bryanhinton.com>
Date: Thu, 22 Jul 2010 20:56:49 -0500
From: Bryan Hinton <bryan@bryanhinton.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
	rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: Greg Smith <greg@2ndquadrant.com>
CC: Scott Marlowe <scott.marlowe@gmail.com>, A J <s5aly@yahoo.com>,
	pgsql-admin@postgresql.org
Subject: Re: How much RAM is too much ?
References: <819397.8724.qm@web120007.mail.ne1.yahoo.com>
	<AANLkTimrtHW5qldCkyWvQneBPZUz19vNyVu28rt8XYUk@mail.gmail.com>
	<4C48D8D8.90503@2ndquadrant.com>
In-Reply-To: <4C48D8D8.90503@2ndquadrant.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

FreeBSD has good kernel level support for DTrace
This is what it looks like on an amd64 FreeBSD stable-8 server with a
custom kernel and a few extra options. The kernel build is straightforward.

Kernel modules loaded on this box
 5    0xfff... ...   dtraceall.ko
 6    0xfff... ...   profile.ko
 7    0xfff... ...   opensolaris.ko
 8    0xfff... ...   cyclic.ko
 9    0xfff... ...   dtrace.ko
10    0xfff... ...   systrace.ko
11    0xfff... ...   sdt.ko
12    0xfff... ...   lockstat.ko
13    0xfff... ...   fbt.ko
14    0xfff... ...   dtnfsclient.ko
15    0xfff... ...   dtmalloc.ko

DTrace is showing 26218 probes and support for the following providers
dtrace dtmalloc nfsclient fbt lockstat mac mac_framework proc priv
callout_execute vfs syscall profile

Of the syscall probes, of which many are very useful for figuring out
what is going on with say a userland daemon that forks, execs, and
context switches back and forth,  dtrace is publishing entry / return
probes for read, write, and other syscalls.  There are function boundary
tracing probes for fsync in the kernel.

Thought you might find that interesting.

Bryan


On 7/22/10 6:48 PM, Greg Smith wrote:
> Scott Marlowe wrote:
>> On some architectures, as you add memory the memory itself becomes
>> slower....Nowadays it's nothing so drastic.
> 
> Last week I saw an Intel system where the measured memory speed dropped
> about 30% when going from half filled (36GB) to completely filled
> (72GB).  So it can still be pretty drastic.  That only turned into about
> a 10% drop in actual throughput running the database though, which was
> more than made up for by reduced reading from the disk due to the extra
> caching.
> 
> Stepping back from that trivia, generally adding memory helps only when
> the working size of the data you access frequently didn't fit in there
> already.  The working set and the total database size are loosely
> related, but not directly.  Other than these weird cases where memory
> slows down when there's too much of it due to motherboard limitations,
> there are few situations where adding more RAM hurts performance.
> 
> However, note that the amount of memory you dedicated to the
> database--what the shared_buffers tunable controls--has been reported by
> multiple people I've talked with to top out at somewhere around 8GB of
> space.  If you increase that parameter beyond that size, it could end up
> hurting performance rather than helping.  Since PostgreSQL also uses the
> operating system cache, this doesn't make for a real limit in the amount
> of memory the database can use.  You just shouldn't give much more than
> this amount to the database.
> 
> A second concern to be aware of is that if you're using Linux in
> particular, it's easy to get the operating system in a state where it
> has cached way too many writes, which causes upticks in latency when the
> database issues its periodic checkpoints.  I can easily make a Linux
> system with 72GB of RAM pause regularly for >30 seconds if I try to
> trigger this behavior.  If you write heavily to the database, it's
> something to be concerned about with that OS and large memory systems.
> 
> In news I don't consider unrelated, FreeBSD is now working on adding
> DTrace support: 
> http://freebsdfoundation.blogspot.com/2010/06/dtrace-userland-project.html
> which will give me yet another reason to consider deploying on that OS
> instead of Linux.
>