Re: Vacuums on large busy databases - Mailing list pgsql-performance

From Francisco Reyes
Subject Re: Vacuums on large busy databases
Date
Msg-id cone.1158277856.620206.75607.5001@35st-server.simplicato.com
Whole thread Raw
In response to Vacuums on large busy databases  (Francisco Reyes <lists@stringsutils.com>)
Responses Re: Vacuums on large busy databases
Re: Vacuums on large busy databases
List pgsql-performance
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?

Also will shared buffers impact inserts/updates at all?
I wish the postgresql.org site docs would mention what will be impacted.

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.

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..

pgsql-performance by date:

Previous
From: Francisco Reyes
Date:
Subject: Re: Vacuums on large busy databases
Next
From: Francisco Reyes
Date:
Subject: Re: Vacuums on large busy databases