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

Re: Load distributed checkpoint

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: "Takayuki Tsunakawa" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Load distributed checkpoint
Date: 2006-12-21 02:55:42
Message-ID: 20061221111949.60B2.ITAGAKI.TAKAHIRO@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Takayuki Tsunakawa" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:

> I have to report a sad result.  Your patch didn't work.  Let's
> consider the solution together.  What you are addressing is very
> important for the system designers in the real world -- smoothing
> response time.

You were running the test on the very memory-depend machine.
> shared_buffers = 4GB / The scaling factor is 50, 800MB of data.
Thet would be why the patch did not work. I tested it with DBT-2, 10GB of
data and 2GB of memory. Storage is always the main part of performace here,
even not in checkpoints.

If you use Linux, it has very unpleased behavior in fsync(); It locks all
metadata of the file being fsync-ed. We have to wait for the completion of
fsync when we do read(), write(), and even lseek().

Almost of your data is in the accounts table and it was stored in a single
file. All of transactions must wait for fsync to the single largest file,
so you saw the bottleneck was in the fsync.

> [Conclusion]
> I believe that the problem cannot be solved in a real sense by
> avoiding fsync/fdatasync().

I think so, too. However, I assume we can resolve a part of the
checkpoint spikes with smoothing of write() alone.

BTW, can we use the same way to fsync? We call fsync()s to all modified
files without rest in mdsync(), but it's not difficult at all to insert
sleeps between fsync()s. Do you think it helps us? One of issues is that
we have to sleep in file unit, which is maybe rough granularity.

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



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-12-21 05:38:08
Subject: Re: Interface for pg_autovacuum
Previous:From: D'Arcy J.M. CainDate: 2006-12-21 01:44:07
Subject: Re: New version of money type

pgsql-patches by date

Next:From: Takayuki TsunakawaDate: 2006-12-21 08:14:13
Subject: Re: Load distributed checkpoint
Previous:From: Glen ParkerDate: 2006-12-21 01:28:56
Subject: Patch(es) to expose n_live_tuples and n_dead_tuples to SQL land

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