Message-ID: <4E705B75.8040502@2ndQuadrant.com>
Date: Wed, 14 Sep 2011 03:44:53 -0400
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: raid array seek performance
References: 
 <CAEV0TzAT0rJ2rWdpkwavVQBsvt9gf-EqVn9Fh9Ee2H-rArDm+Q@mail.gmail.com>
In-Reply-To: 
 <CAEV0TzAT0rJ2rWdpkwavVQBsvt9gf-EqVn9Fh9Ee2H-rArDm+Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 09/13/2011 03:13 PM, Samuel Gendler wrote:
> Bonnie++ delivered the expected huge throughput for sequential read 
> and write.  It seems in line with other benchmarks I found online. 
>  However, we are only seeing 180 seeks/sec, but seems quite low.

I wouldn't worry about that if the sequential rates are good.  The 
bonnie++ seeks test has been giving me increasingly useless results 
recently on modern hardware.  And bonnie++ 1.96 continues to give me 
enough weird values that I'm still using 1.03e as my standard version.

If you want to get a useful measurement of seeks/second, setup 
pgbench-tools with a SELECT-only test, and create a database that's 2 to 
4X as big as RAM.  The TPS result you get from that is a much more 
useful number for real-world seeks than this.

I'm working on a tool to directly benchmark seek performance in a way 
that's useful for what people really want to know nowadays.  That's 
going live to the world at the end of the month, at #PgWest:  
http://pgwest2011.sched.org/event/875b87d8d237bef3a53ab27ac9c8057c

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us