Re: How much RAM is too much ?

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.
>