Re: Load distributed checkpoint

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Load distributed checkpoint
Date: 2006-12-28 01:11:52
Message-ID: 20061228093225.5FA8.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> > 566.973777
> > 327.158222 <- (1) write()
> > 560.773868 <- (2) sleep
> > 544.106645 <- (3) fsync()
>
> OK, so you are saying that performance dropped only during the write(),
> and not during the fsync()? Interesting.

Almost yes, but there is a small drop in fsync. (560->540)

> I would like to know the
> results of a few tests just like you reported them above:
>
> 1a) write spread out over 30 seconds
> 1b) write with no delay
>
> 2a) sleep(0)
> 2b) sleep(30)
>
> 3) fsync
>
> I would like to know the performance at each stage for each combination,
> e.g. when using 1b, 2a, 3, performance during the write() phase was X,
> during the sleep it was Y, and during the fsync it was Z. (Of course,
> sleep(0) has no stage timing.)

I'm thinking about generalizing your idea; Adding three parameters
(checkpoint_write, checkpoint_naptime and checkpoint_fsync)
to control sleeps in each stage.

1) write() spread out over 'checkpoint_write' seconds.
2) sleep 'checkpoint_naptime' seconds between write() and fsync().
3) fsync() spread out over 'checkpoint_fsync' seconds.

If three parameter are all zero, checkpoints behave as the same as now.
If checkpoint_write = checkpoint_timeout and other two are zero,
it is just like my proposal before.

As you might expect, I intend the above only for development purpose.
Additinal three parameters are hard to use for users. If we can pull out
some proper values from the tests, we'd better to set those values as
default. I assume we can derive them from existing checkpoint_timeout.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-12-28 01:41:23 Re: [BUGS] BUG #2846: inconsistent and confusing
Previous Message David Fetter 2006-12-28 00:37:24 Re: (SETOF) RECORD AS complex_type

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-12-28 01:41:23 Re: [BUGS] BUG #2846: inconsistent and confusing
Previous Message Roman Kononov 2006-12-27 23:47:05 Re: [BUGS] BUG #2846: inconsistent and confusing handling