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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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