Mike C <smith.not.western@xxxxxxxxx> writes: > I have been using table 17-2, Postgres Shared Memory Usage > (http://www.postgresql.org/docs/9.1/interactive/kernel-resources.html) > to calculate approximately how much memory the server will use. I'm > using Postgres 9.1 on a Linux 2.6 (RHEL 6) 64bit system, with 8GB RAM. > Database is approximately 5GB, and is a mixture of read/write. > Postgres is occasionally being killed by the linux oom-killer. I am > trying to understand how much memory postgres could use, and how to > change the configuration to bring it down to a level that won't get it > killed. Basically, you can't fix it that way, at least not if you want to have a sane configuration. The problem is misdesign of the OOM killer: it will count the shared memory block against the postmaster *once for each child process*. The only realistic solution is to turn off OOM kill for the postmaster (and maybe its children too, or maybe you'd rather have them immune as well). The former is pretty easy to do if you're launching the postmaster from a root-privileged initscript. I think most prepackaged versions of PG are set up to be able to do this already. If you want the children OOM-killable it requires a source-code tweak as well, since that property is normally inherited. But anyway, your calculations are totally off: > Shared Disk Buffers = 36,077,725,286,400 > = (block_size + 208) * shared_buffers > = (8192 + 208) * 4294967296 > = ~33TB I think you've multiplied by the block size one time too many. Ditto for WAL buffers. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
