Skip site navigation (1) Skip section navigation (2)

Re: moving pg_xlog -- yeah, it's worth it!

From: Ben Chobot <bench(at)silentmedia(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: moving pg_xlog -- yeah, it's worth it!
Date: 2010-02-23 22:14:02
Message-ID: 4EBF0BC6-38EC-46BB-98EE-A181647808EC@silentmedia.com (view raw or flat)
Thread:
Lists: 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.

In response to

pgsql-performance by date

Next:From: negoraDate: 2010-02-23 22:52:56
Subject: Re: Internal operations when the planner makes a hash join.
Previous:From: Kevin GrittnerDate: 2010-02-23 21:45:21
Subject: Re: Internal operations when the planner makes a hash join.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group