Tom Lane wrote:
Ok, I can do this, but why can more memory be harmful?Because you've left no room for anything else? The kernel, the various other daemons, the Postgres code itself, and the local memory for each Postgres process all require more than zero space. So does this mean that the stuff you mentioned needs more than 1 GB of memory? I seem to have undererstimated the amount of memory that is needed for these purposes. :( Even more to the point, with such a large shared-buffer space, the kernel probably will be tempted to swap out whatever parts of it seem less used at the moment. That is far more harmful to performance than not having had the buffer in the first place --- it can easily triple the amount of disk I/O involved. (Thought experiment: dirty buffer is written to disk, versus dirty buffer is swapped out to disk, then later has to be swapped in so it can be written to wherever it should have gone.) Bottom line is that PG shared buffers are not so important as to deserve 3/4ths of your RAM. Thanks for your tips! I have changed the "shared_buffers" setting back to 2 GB. It was set to 2 GB before, but we also had "out of memory" errors with this setting, so I raised it to 3 GB. Could you please help me understand what's happening? The server is a dedicated database server. Few other demons are running, most of them are system services that do not consume a considerable amount of memory. No web server or similar is running on this machine. Moreover, the output of "free" confuses me: db2:~ # free -m total used free shared buffers cached Mem: 3954 3724 229 0 0 3097 -/+ buffers/cache: 627 3326 Swap: 2055 628 1426 Doesn't that mean that plenty of memory is unused? I always thought that the memory used for buffers and caches can be thought of as free memory. Isn't this correct? Regarding the memory needs of the PostgreSQL server itself: Is there any estimation how much memory will be needed besides the shared buffers? What exactly does "out of memory" mean? Who requested the memory and why could this memory request not be fulfilled? I can post the memory overview from the log file, but I don't know if it's considered impolite to post so many lines to this mailing list. Thanks a lot again for your help, Christian -- Deriva GmbH Tel.: +49 551 489500-42 Financial IT and Consulting Fax: +49 551 489500-91 Hans-Böckler-Straße 2 http://www.deriva.de D-37079 Göttingen Deriva CA Certificate: http://www.deriva.de/deriva-ca.cer |