From: Gavin Flower <GavinFlower@archidevsys.co.nz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses
Date: Thu, 04 Jul 2013 07:23:03 +1200
Message-ID: <51D47A17.6000809@archidevsys.co.nz> (raw)
In-Reply-To: <CA+TgmoZsh0zRdLoPh+PaGswMKqHRLZcAb89O+XRQLhSsjYOaYg@mail.gmail.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>
<51CD873A.5070705@lab.ntt.co.jp>
<51D3DE55.6030901@lab.ntt.co.jp>
<CA+TgmoZsh0zRdLoPh+PaGswMKqHRLZcAb89O+XRQLhSsjYOaYg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 04/07/13 01:31, Robert Haas wrote:
> On Wed, Jul 3, 2013 at 4:18 AM, KONDO Mitsumasa
> <kondo.mitsumasa@lab.ntt.co.jp> wrote:
>> I tested and changed segsize=0.25GB which is max partitioned table file size and
>> default setting is 1GB in configure option (./configure --with-segsize=0.25).
>> Because I thought that small segsize is good for fsync phase and background disk
>> write in OS in checkpoint. I got significant improvements in DBT-2 result!
> This is interesting. Unfortunately, it has a significant downside:
> potentially, there will be a lot more files in the data directory. As
> it is, the number of files that exist there today has caused
> performance problems for some of our customers. I'm not sure off-hand
> to what degree those problems have been related to overall inode
> consumption vs. the number of files in the same directory.
>
> If the problem is mainly with number of of files in the same
> directory, we could consider revising our directory layout. Instead
> of:
>
> base/${DBOID}/${RELFILENODE}_{FORK}
>
> We could have:
>
> base/${DBOID}/${FORK}/${RELFILENODE}
>
> That would move all the vm and fsm forks to separate directories,
> which would cut down the number of files in the main-fork directory
> significantly. That might be worth doing independently of the issue
> you're raising here. For large clusters, you'd even want one more
> level to keep the directories from getting too big:
>
> base/${DBOID}/${FORK}/${X}/${RELFILENODE}
>
> ...where ${X} is two hex digits, maybe just the low 16 bits of the
> relfilenode number. But this would be not as good for small clusters
> where you'd end up with oodles of little-tiny directories, and I'm not
> sure it'd be practical to smoothly fail over from one system to the
> other.
>
16 bits ==> 4 hex digits
Could you perhaps start with 1 hex digit, and automagically increase it
to 2, 3, .. as needed? There could be a status file at that level, that
would indicate the current number of hex digits, plus a temporary
mapping file when in transition.
Cheers,
Gavin
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: GavinFlower@archidevsys.co.nz, robertmhaas@gmail.com, kondo.mitsumasa@lab.ntt.co.jp, hlinnakangas@vmware.com
Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses
In-Reply-To: <51D47A17.6000809@archidevsys.co.nz>
* 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