On Wed, Mar 26, 2014 at 6:21 AM, Alexey Vasiliev <leopard_ne@xxxxxxxx> wrote: > I read from several sources, what maximum shared_buffers is 8GB. > > Does this true? If yes, why exactly this number is maximum number of > shared_buffers for good performance (on Linux 64-bits)? On most machines the limit is higher than you'd ever want to set it. I have a set of servers with 1TB RAM and shared buffers on them is set to 10G and even that is probably higher than it needs to be. The old 1/4 of memory advice comes from the days when db server memory was in the 1 to 16GB range and even then it was more of a starting place. It has been found through experience and experiment that few setups can use more shared buffers than a few gigabytes and get better performance. On Wed, Mar 26, 2014 at 7:24 AM, Markella Skempri <markella_skembri@xxxxxxxxxxx> wrote: > I wanted to follow up from this question. I'm running on 9.3.4 > My DB server has 32GB ram so I have assigned 8GB shared_buffer_memory. It is > quite a big db but with not much traffic. When there is traffic, it's > usually big. > > Lately, the kernel has been killing the postmaster for having assigned too > much shared memory. Latest crash was when loading a 500MB file. > > Should I reduce the shared buffers in order for this to be more robust? It's not JUST your shared_buffers here. What are your changed settings in postgresql.conf? Specifically work_mem, max_connections, temp_buffers and to a lesser extent maintenance_work_mem. Here's the thing. If you set shared_buffers, work_mem, and max_connections too low you get a minor problem. Some apps can't connect, pg is a little slow. If you set them too high you start killing your DB with the OOM killer which is a major problem. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
