On 14-Sep-06, at 7:50 PM, Francisco Reyes wrote:
Dave Cramer writes:
personally, I'd set this to about 6G. This doesn't actually
consume memory it is just a setting to tell postgresql how much
memory is being used for cache and kernel buffers
Gotcha. Will increase further.
regarding shared buffers I'd make this much bigger, like 2GB or more
Will do 2GB on the weekend. From what I read this requires shared
memory so have to restart my machine (FreeBSD).
if I plan to give shared buffers 2GB, how much more over that
should I give the total shared memory kern.ipc.shmmax? 2.5GB?
I generally make it slightly bigger. is shmmax the size of the
maximum chunk allowed or the total ?
Also will shared buffers impact inserts/updates at all?
I wish the postgresql.org site docs would mention what will be
impacted.
Yes, it will, however not as dramatically as what you are seeing with
effective_cache
Comments like: This setting must be at least 16, as well as at
least twice the value of max_connections; however, settings
significantly higher than the minimum are usually needed for good
performance.
Are usefull, but could use some improvement.. increase on what? All
performance? inserts? updates? selects?
For instance, increasing effective_cache_size has made a noticeable
difference in selects. However as I talk to the developers we are
still doing marginally in the inserts. About 150/min.
The reason is that with effective_cache the select plans changed (for
the better) ; it's unlikely that the insert plans will change.
There is spare CPU cycles, both raid cards are doing considerably
less they can do.. so next I am going to try and research what
parameters I need to bump to increase inserts. Today I increased
checkpoint_segments from the default to 64. Now looking at
wall_buffers.
It would be most helpfull to have something on the docs to specify
what each setting affects most such as reads, writes, updates,
inserts, etc..
It's an art unfortunately.
Dave
