From: Bryan Hinton <bryan@bryanhinton.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: A J <s5aly@yahoo.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: How much RAM is too much ?
Date: Thu, 22 Jul 2010 20:56:49 -0500
Message-ID: <4C48F6E1.6020004@bryanhinton.com> (raw)
In-Reply-To: <4C48D8D8.90503@2ndquadrant.com>
References: <819397.8724.qm@web120007.mail.ne1.yahoo.com>
<AANLkTimrtHW5qldCkyWvQneBPZUz19vNyVu28rt8XYUk@mail.gmail.com>
<4C48D8D8.90503@2ndquadrant.com>
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.
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: bryan@bryanhinton.com, greg@2ndquadrant.com, scott.marlowe@gmail.com, s5aly@yahoo.com
Subject: Re: How much RAM is too much ?
In-Reply-To: <4C48F6E1.6020004@bryanhinton.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox