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. > -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
