Re: moving pg_xlog -- yeah, it's worth it! - Mailing list pgsql-performance

From Ben Chobot
Subject Re: moving pg_xlog -- yeah, it's worth it!
Date
Msg-id 4EBF0BC6-38EC-46BB-98EE-A181647808EC@silentmedia.com
Whole thread Raw
In response to Re: moving pg_xlog -- yeah, it's worth it!  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-performance
On Feb 23, 2010, at 2:23 PM, Kevin Grittner wrote:


Here are the values from our two largest and busiest systems (where
we found the pg_xlog placement to matter so much).  It looks to me
like a more aggressive bgwriter would help, yes?

cir=> select * from pg_stat_bgwriter ;
-[ RECORD 1 ]------+------------
checkpoints_timed  | 125996
checkpoints_req    | 16932
buffers_checkpoint | 342972024
buffers_clean      | 343634920
maxwritten_clean   | 9928
buffers_backend    | 575589056
buffers_alloc      | 52397855471

cir=> select * from pg_stat_bgwriter ;
-[ RECORD 1 ]------+------------
checkpoints_timed  | 125992
checkpoints_req    | 16840
buffers_checkpoint | 260358442
buffers_clean      | 474768152
maxwritten_clean   | 9778
buffers_backend    | 565837397
buffers_alloc      | 71463873477

Current settings:

bgwriter_delay = '200ms'
bgwriter_lru_maxpages = 1000
bgwriter_lru_multiplier = 4

Any suggestions on how far to push it?

I don't know how far to push it, but you could start by reducing the delay time and observe how that affects performance.

pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Internal operations when the planner makes a hash join.
Next
From: negora
Date:
Subject: Re: Internal operations when the planner makes a hash join.