From: KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>
To: Greg Smith <greg@2ndQuadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
To: didier <did447@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses
Date: Thu, 25 Jul 2013 19:11:13 +0900
Message-ID: <51F0F9C1.9080207@lab.ntt.co.jp> (raw)
In-Reply-To: <51EDF01A.4050006@2ndQuadrant.com>
References: <51B5AFB1.5030404@lab.ntt.co.jp>
<51BDCB6C.1090507@vmware.com>
<51BEB6F5.7070907@lab.ntt.co.jp>
<51C40EF4.1080201@lab.ntt.co.jp>
<51C9D03B.10107@vmware.com>
<CA+TgmoZ+ofyg4e+hRBTnnfrC7M2ATX-Pg0k4AtyHx60A+_DFhQ@mail.gmail.com>
<51C9FD5C.5050706@vmware.com>
<CA+TgmoZj-0CFLbjceMtgi1t_=hpfe9z8uSa+D0g77sNYcFy04w@mail.gmail.com>
<51E2F865.8030406@2ndQuadrant.com>
<CA+TgmoY=GTANT6uNV4Ds6H6K0sRuWxSHErOaHSVDLvMPxYwqDA@mail.gmail.com>
<51E80CBC.10204@2ndQuadrant.com>
<51E8F080.4040506@lab.ntt.co.jp>
<51E943A1.9030702@2ndQuadrant.com>
<51ECF2CF.6080109@lab.ntt.co.jp>
<51EDF01A.4050006@2ndQuadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hi,
I understand why my patch is faster than original, by executing Heikki's patch.
His patch execute write() and fsync() in each relation files in write-phase in
checkpoint. Therefore, I expected that write-phase would be slow, and fsync-phase
would be fast. Because disk-write had executed in write-phase. But fsync time in
postgresql with his patch is almost same time as original. It's very mysterious!
I checked /proc/meminfo in executing benchmark and other resources. As a result,
this was caused by separating checkpointer process and writer process. In 9.1 or
older, checkpoint and background-write are executed in writer process by serial
schedule. But in 9.2 or later, it is executed by parallel schedule, regardless
executing checkpoint. Therefore, less fsync and long-term fsync schedule method
which likes my patch are so faster. Because waste disk-write was descend by
thease method. In worst case his patch, same peges disk-write are executed twice
in one checkpoint, moreover it might be random disk-write.
By the way, when dirty buffers which have always under dirty_background_ratio *
physical memory / 100, write-phase does not disk-write at all. Therefore, in
fsync-phase disk-write all of dirty buffer. So when this case, write-schedule is
not making sense. It's very heavy and waste, but it might not change by OS and
postgres parameters. I set small dirty_backjground_ratio, but the result was very
miserable...
Now, I am confirming my theory by dbt-2 benchmark in lru_max_pages = 0. And I
will be told about OS background-writing mechanism by my colleague who is kernel
hacker next week.
What do you think?
Best regards,
--
Mitsumasa KONDO
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: kondo.mitsumasa@lab.ntt.co.jp, greg@2ndQuadrant.com, robertmhaas@gmail.com, hlinnakangas@vmware.com, did447@gmail.com
Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses
In-Reply-To: <51F0F9C1.9080207@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox