Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UuNGS-0003vt-AQ for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jul 2013 13:38:32 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1UuNGR-0001H8-QY for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jul 2013 13:38:31 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UuNGR-0001H2-0w for pgsql-hackers@postgresql.org; Wed, 03 Jul 2013 13:38:31 +0000 Received: from moutng.kundenserver.de ([212.227.126.186]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UuNGO-0002zl-A5 for pgsql-hackers@postgresql.org; Wed, 03 Jul 2013 13:38:30 +0000 Received: from anarazel.de (p5DDC48E3.dip0.t-ipconnect.de [93.220.72.227]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LkUcJ-1UOKd21PoJ-00buIx; Wed, 03 Jul 2013 15:38:23 +0200 Received: by anarazel.de (Postfix, from userid 1000) id 8207C10051F; Wed, 3 Jul 2013 15:39:43 +0200 (CEST) Date: Wed, 3 Jul 2013 15:39:43 +0200 From: Andres Freund To: KONDO Mitsumasa Cc: Robert Haas , Heikki Linnakangas , PostgreSQL-development Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses Message-ID: <20130703133943.GA5667@awork2.anarazel.de> 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> <51C9FD5C.5050706@vmware.com> <51CD873A.5070705@lab.ntt.co.jp> <51D3DE55.6030901@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D3DE55.6030901@lab.ntt.co.jp> X-Provags-ID: V02:K0:s+ac7EeJfpV0gSnpALSH8TcJpYZcWZAch/RxZFvjidw WrusDQyzpPPU/uQj9eFlmPeoV7/pUDOpXTkAThDNIZi3W/F3pO xPSg6DXHKUImASLcrnN7nnJTpO7oj9i0cgv03tkcGZqVREjRiL MhpWpsnbpkshRT5zShS9P26Chpo6AFobcDaYtukqbi5R0yBtcC JXHMc4Bdb2H1GZNKMVg6acIgbuXWRNkDVEyptkpICrBZ96YTT3 RdDb83X72fgKbUTnD521Fh6s1cedpz8gENUPIw8JhtCYmbkeaD ueAIuM0LKCtdgiZ+foUNKUaiWmdg+E5vRA/WlhncGlHuX/sOme pAFXTcaPG8TEyw82pVX7D9hy0hSUchk32CJzYydWq X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2013-07-03 17:18:29 +0900, KONDO Mitsumasa wrote: > Hi, > > 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! > > * Performance result in DBT-2 (WH340) > | NOTPM 90%tile Average Maximum > -----------------------------+--------------------------------------- > original_0.7 (baseline) | 3474.62 18.348328 5.739 36.977713 > fsync + write | 3586.85 14.459486 4.960 27.266958 > fsync + write + segsize=0.25 | 3661.17 8.28816 4.117 17.23191 > > Changing segsize with my checkpoint patches improved original over 50% at 90%tile > and maximum response time. Hm. I wonder how much of this could be gained by doing a sync_file_range(SYNC_FILE_RANGE_WRITE) (or similar) either while doing the original checkpoint-pass through the buffers or when fsyncing the files. Presumably the smaller segsize is better because we don't completely stall the system by submitting up to 1GB of io at once. So, if we were to do it in 32MB chunks and then do a final fsync() afterwards we might get most of the benefits. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers