Re: shared_buffers/effective_cache_size on 96GB server - Mailing list pgsql-performance

From Bruce Momjian
Subject Re: shared_buffers/effective_cache_size on 96GB server
Date
Msg-id 20121010160534.GD11892@momjian.us
Whole thread Raw
In response to shared_buffers/effective_cache_size on 96GB server  (Strahinja Kustudić <strahinjak@nordeus.com>)
List pgsql-performance
On Wed, Oct 10, 2012 at 09:12:20AM +0200, Strahinja Kustudić wrote:
> Hi everyone,
>
> I have a Postgresql 9.1 dedicated server with 16 cores, 96GB RAM and RAID10 15K
> SCSI drives which is runing Centos 6.2 x64. This server is mainly used for
> inserting/updating large amounts of data via copy/insert/update commands, and
> seldom for running select queries.
>
> Here are the relevant configuration parameters I changed:
>
> shared_buffers = 10GB
> effective_cache_size = 90GB
> work_mem = 32MB
> maintenance_work_mem = 512MB
> checkpoint_segments = 64
> checkpoint_completion_target = 0.8
>
> My biggest concern are shared_buffers and effective_cache_size, should I
> increase shared_buffers and decrease effective_cache_size? I read that values
> above 10GB for shared_buffers give lower performance, than smaller amounts?
>
> free is currently reporting (during the loading of data):
>
> $ free -m
>              total       used       free     shared    buffers     cached
> Mem:         96730      96418        311          0         71      93120
> -/+ buffers/cache:       3227      93502
> Swap:        21000         51      20949
>
> So it did a little swapping, but only minor, still I should probably decrease
> shared_buffers so there is no swapping at all.

You might want to read my blog entry about swap space:

    http://momjian.us/main/blogs/pgblog/2012.html#July_25_2012

It is probably swapping unused memory _out_ to make more use of RAM for
cache.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Hyperthreading (was: Two identical systems, radically different performance)
Next
From: Korisk
Date:
Subject: hash aggregation