Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 338F31337BA1 for ; Sun, 6 Feb 2011 21:37:08 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 88352-01 for ; Mon, 7 Feb 2011 01:37:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mail.postgresql.org (Postfix) with ESMTP id 5552E1337BA3 for ; Sun, 6 Feb 2011 21:37:00 -0400 (AST) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MRhPx-1PawRE049h-00SymW; Mon, 07 Feb 2011 02:36:57 +0100 Message-ID: <4D4F4CB7.50003@2ndquadrant.com> Date: Sun, 06 Feb 2011 20:36:55 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Benjamin Krajmalnik CC: pgsql-performance@postgresql.org Subject: Re: Need some help analyzing some benchmarks References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030401020705090004050406" X-Provags-ID: V02:K0:qPS1PGmgvQOGwwDjcI0kvxKlocvjU2w7dGkiAQStBjB FGWBrYttbw7S5AiCZOdipQMj9J3kNAZcoti3A4Fb38YzbWGShk xI+EqBqf8dmZDPPEimLjx7TWVIBvcV2O04bfQqmGQ0M356uIIB mRUP84Z9MEzbhld6rZjW2B73hHPwGAK+rdjgqbQIfGQnacx7GB MeOfX9I4vYB2bQ7WYEMOYj4AX4+0mpZOB6bWVBljf8= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201102/273 X-Sequence-Number: 42411 This is a multi-part message in MIME format. --------------030401020705090004050406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benjamin Krajmalnik wrote: > > My data partition is 12 drives in RAID 1+0 (2.7TB) running UFS2. > Vfs.read_max has been set to 32, and no other tuning has been done... > > Not having anything to compare it to, I do not know if these are > decent numbers or not -- they are definitely slower than a similar > setup which was posted recently using XFS on Linux, but I have not > found anything in FreeBSD using UFS2 to compare it to. What strikes > me in particular is that the write performance is higher than the read > performance -- I would have intuitively expected it to be the other > way around. > Generally write speed higher than read means that volume read-ahead still isn't high enough for the OS to keep the disk completely busy. Try increasing read_max further; I haven't done many such tests on FreeBSD, but as far as I know settings of 128 and 256 are generally where read performance peaks on that OS. You should see sequential read speed go up as you increase that parameter, eventually levelling off. When you reach that point you've found the right setting. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books --------------030401020705090004050406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Benjamin Krajmalnik wrote:

My data partition is 12 drives in RAID 1+0 (2.7TB) running UFS2. Vfs.read_max has been set to 32, and no other tuning has been done...

Not having anything to compare it to, I do not know if these are decent numbers or not – they are definitely slower than a similar setup which was posted recently using XFS on Linux, but I have not found anything in FreeBSD using UFS2 to compare it to. What strikes me in particular is that the write performance is higher than the read performance – I would have intuitively expected it to be the other way around.

Generally write speed higher than read means that volume read-ahead still isn't high enough for the OS to keep the disk completely busy. Try increasing read_max further; I haven't done many such tests on FreeBSD, but as far as I know settings of 128 and 256 are generally where read performance peaks on that OS. You should see sequential read speed go up as you increase that parameter, eventually levelling off. When you reach that point you've found the right setting.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

--------------030401020705090004050406--