Hi,
On Thu, 28 Jul 2005, Kari Lavikka wrote:
Advertising
> ----------------->8 Relevant rows from postgresql.conf 8<-----------------
>
> shared_buffers = 15000 # min 16, at least max_connections*2, 8KB each
> work_mem = 1536 # min 64, size in KB
As an aside, I'd increase work_mem -- but it doesn't sound like that is
your problem.
> maintenance_work_mem = 32768 # min 1024, size in KB
>
> max_fsm_pages = 1000000 # min max_fsm_relations*16, 6 bytes each
> max_fsm_relations = 5000 # min 100, ~50 bytes each
>
> vacuum_cost_delay = 15 # 0-1000 milliseconds
> vacuum_cost_limit = 120 # 0-10000 credits
>
> bgwriter_percent = 2 # 0-100% of dirty buffers in each round
>
> fsync = true # turns forced synchronization on or off
> # fsync, fdatasync, open_sync, or
> open_datasync
> wal_buffers = 128 # min 4, 8KB each
Some benchmarking results out today suggest that wal_buffers = 1024 or
even 2048 could greatly assist you.
> commit_delay = 80000 # range 0-100000, in microseconds
> commit_siblings = 10 # range 1-1000
This may explain the fact that you've got backed up queries and idle CPU
-- I'm not certain though. What does disabling commit_delay do to your
situation?
Gavin
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
