On Thu, Feb 4, 2010 at 2:21 PM, Jeff Ross <jr...@openvistas.net> wrote: > kern.shminfo.shmall=512000 > kern.shminfo.shmmax=768000000
Oh, when I said it was safe to crank shmmax I didn't know you'd be setting the bufcache to huge numbers too. ;) > available memory in the server. I tried setting mine to 980MBs (4GB of ram) > and that meant setting kern.shminfo.shmmax to 1GB just to get postgres to > start. Later I found out that each process on an i386 is limited to 1GB, so > I backed that off to 600MB. As I pointed out in that thread, the 1GB limit does not apply to shared memory. > What I will try next is setting postgres's shared_buffers to 1/4 of 1GB, > since that is really the amount of available memory I have per postmaster, > and dropping kern.shminfo.shmmax accordingly. I know that will run but not > terribly fast, unless maybe kicking kern.bufcachepercent back up to 90% will > help and not cause a panic. Even so, I'm not sure how you're interpreting these numbers. shmmax is total across all processes, not process. Your statement seems to imply a shm setting that's per postmaster, based on dividing total RAM between them, which would also leave no memory free for your 90% buffer cache. The long and short of the problem is that you have a certain amount of RAM that has to be shared by all the processes' private address spaces, their shm segments, and the buffer cache. Obviously this can't go over 100%. But on top of it, there's also kernel overhead (secondary resources) just to keep track of all the previous (primary resources). This takes both RAM and kernel address space (out of a rather restricted pool). The limits exist not just to constrain how many resources are used for a particular purpose, but also so there's an upper bound on the secondary resources used to track the primary ones. It's like a rubber band. Bob's patch lets you stretch it farther in one direction, but you can't simultaneously stretch in a dozen ways at once.
