Date: Sat, 6 Dec 2014 08:08:28 -0500
From: Bruce Momjian <bruce@momjian.us>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: intel s3500 -- hot stuff
Message-ID: <20141206130828.GA1314@momjian.us>
References: 
 <CAHyXU0yaUG9R_E5=1gdXhD-MpWR=Gr=4=EHFD_fRid2+SCQrqA@mail.gmail.com>
 <CAHyXU0yiVvfQAnR9cyH=HWh1WbLRsioe=mzRJTHwtr=2azsTdQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAHyXU0yiVvfQAnR9cyH=HWh1WbLRsioe=mzRJTHwtr=2azsTdQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On Wed, Nov  5, 2014 at 12:09:16PM -0600, Merlin Moncure wrote:
> effective_io_concurrency 1: 46.3 sec, ~ 170 mb/sec peak via iostat
> effective_io_concurrency 2:  49.3 sec, ~ 158 mb/sec peak via iostat
> effective_io_concurrency 4:  29.1 sec, ~ 291 mb/sec peak via iostat
> effective_io_concurrency 8:  23.2 sec, ~ 385 mb/sec peak via iostat
> effective_io_concurrency 16:  22.1 sec, ~ 409 mb/sec peak via iostat
> effective_io_concurrency 32:  20.7 sec, ~ 447 mb/sec peak via iostat
> effective_io_concurrency 64:  20.0 sec, ~ 468 mb/sec peak via iostat
> effective_io_concurrency 128:  19.3 sec, ~ 488 mb/sec peak via iostat
> effective_io_concurrency 256:  19.2 sec, ~ 494 mb/sec peak via iostat
> 
> Did not see consistent measurable gains > 256
> effective_io_concurrency.  Interesting that at setting of '2' (the
> lowest possible setting with the feature actually working) is
> pessimal.

Very interesting.  When we added a per-tablespace random_page_cost,
there was a suggestion that we might want to add per-tablespace
effective_io_concurrency someday:

	commit d86d51a95810caebcea587498068ff32fe28293e
	Author: Robert Haas <rhaas@postgresql.org>
	Date:   Tue Jan 5 21:54:00 2010 +0000
	
	    Support ALTER TABLESPACE name SET/RESET ( tablespace_options ).
	
	    This patch only supports seq_page_cost and random_page_cost as parameters,
	    but it provides the infrastructure to scalably support many more.
	    In particular, we may want to add support for effective_io_concurrency,
	    but I'm leaving that as future work for now.
	
	    Thanks to Tom Lane for design help and Alvaro Herrera for the review.

It seems that time has come.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance