Subject: Re: Testing Sandforce SSD
From: Hannu Krosing <hannu@2ndquadrant.com>
To: Yeb Havinga <yebhavinga@gmail.com>
Cc: Scott Marlowe <scott.marlowe@gmail.com>,
 Greg Smith <greg@2ndquadrant.com>,
	Josh Berkus <josh@agliodbs.com>, pgsql-performance@postgresql.org
In-Reply-To: <4C57D5FD.9040306@gmail.com>
References: <4C4A9452.9070100@gmail.com>	<4C4B1F84.5030306@2ndquadrant.com>
	<4C4B4B41.7000800@2ndquadrant.com>	<4C52E957.8020304@gmail.com>
	<AANLkTinNX63EsRtNjtKeeygymWjH8VA3EWwxBzXGCy0=@mail.gmail.com>
	<4C56DD8B.6050303@gmail.com>	<4C5744F5.3020805@agliodbs.com>
	<4C575DCF.3050700@2ndquadrant.com>
	<AANLkTikQ=CUSoRy+MxYA2TAfk2hdipA4Uz_qYXyu+yhR@mail.gmail.com>
	<4C57D5FD.9040306@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 03 Aug 2010 12:08:42 +0300
Message-ID: <1280826522.14579.66.camel@hvost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Tue, 2010-08-03 at 10:40 +0200, Yeb Havinga wrote:
> se note that the 10% was on a slower CPU. On a more recent CPU the 
> difference was 47%, based on tests that ran for an hour.

I am not surprised at all that reading and writing almost twice as much
data from/to disk takes 47% longer. If less time is spent on seeking the
amount of data starts playing bigger role.

>  That's why I 
> absolutely agree with Merlin Moncure that more testing in this 
> department is welcome, preferably by others since after all I could be 
> on the pay roll of OCZ :-)

:)


> I looked a bit into Bonnie++ but fail to see how I could do a test that 
> somehow matches the PostgreSQL setup during the pgbench tests (db that 
> fits in memory, 

Did it fit in shared_buffers, or system cache ?

Once we are in high tps ground, the time it takes to move pages between
userspace and system cache starts to play bigger role.

I first noticed this several years ago, when doing a COPY to a large
table with indexes took noticably longer (2-3 times longer) when the
indexes were in system cache than when they were in shared_buffers.

> so the test is actually how fast the ssd can capture 
> sequential WAL writes and fsync without barriers, mixed with an 
> occasional checkpoint with random write IO on another partition). Since 
> the WAL writing is the same for both block_size setups, I decided to 
> compare random writes to a file of 5GB with Oracle's Orion tool:

Are you sure that you are not writing full WAL pages ?

Do you have any stats on how much WAL is written for 8kb and 4kb test
cases ?

And for other disk i/o during the tests ?


-- 
Hannu Krosing   http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability 
   Services, Consulting and Training