Wells Oliver <woliver@xxxxxxxxxx> wrote: > This has happened twice over the last couple of nights: > > 2011-05-30 02:08:27 PDT LOG: server process (PID 29979) was > terminated by signal 9: Killed > 2011-05-30 02:08:31 PDT FATAL: could not create shared memory > segment: Cannot allocate memory > To reduce the request size (currently 6595420160 bytes), reduce > PostgreSQL's shared_buffers parameter [...] > The value of shared_buffers is set to 6GB, work_mem is 64MB, > maintenance_work_mem is 128MB, effective_cache_size is 4GB. > > max_connections is set to 200. > > Any ideas here? The system has 12GB; raising the shared_buffers > seems reasonable but 6GB also feels like it should be sufficient. You're probably overcommitting memory and running afoul of the oom killer. You've got an actual 12MB, but you can easily allocate up to shared_buffers + (user_connections * work_mem), which is 18.5 GB. I would start by reducing shared_buggers to 3GB or less, and cut work_mem in half. Then I would get a connection pooler set up to funnel 200 client-side connections through a pool of 10 or 20 database connections. Then I would try edging up work_mem while monitoring performance and memory usage. -Kevin -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
