Date:	Fri, 18 Jan 2013 13:25:43 -0800
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	device-mapper development <dm-devel@...hat.com>
Cc:	Amit Kale <akale@...c-inc.com>,
	"linux-bcache@...r.kernel.org" <linux-bcache@...r.kernel.org>,
	"kent.overstreet@...il.com" <kent.overstreet@...il.com>,
	Mike Snitzer <snitzer@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	lsf-pc@...ts.linux-foundation.org
Subject: [LSF/MM TOPIC] Re: [dm-devel] Announcement: STEC EnhanceIO SSD
 caching software for Linux kernel

Since Joe is putting together a testing tree to compare the three caching
things, what do you all think of having a(nother) session about ssd caching at
this year's LSFMM Summit?

[Apologies for hijacking the thread.]
[Adding lsf-pc to the cc list.]

--D

On Fri, Jan 18, 2013 at 12:36:42PM -0600, Jason Warr wrote:
> 
> On 01/18/2013 11:44 AM, Amit Kale wrote:
> >> As much as I dislike Oracle that is one of my primary applications.  I
> >> > am attempting to get one of my customers to setup an Oracle instance
> >> > that is modular in that I can move the storage around to fit a
> >> > particular hardware setup and have a consistent benchmark that they use
> >> > in the real world to gauge performance.  One of them is a debit card
> >> > transaction clearing entity on multi-TB databases so latency REALLY
> >> > matters there.  
> > I am curious as to how SSD latency matters so much in the overall transaction times.
> >
> > We do a lot of performance measurements using SQL database benchmarks. Transaction times vary a lot depending on location of data, complexity of the transaction etc. Typically TPM (transactions per minute) is of primary interest for TPC-C.
> >
> 
> It's not specifically SSD latency.  It's I/O transaction latency that
> matters.  This particular application is very sensitive to that because
> it is literally someone standing at a POS terminal swiping a
> debit/credit card.  You only have a couple of seconds after the PIN is
> entered for the transaction to go through your network, application
> server to authorize against a DB and back to the POS.
> 
> The entire I/O stack on the DB is only a small time-slice of that round
> trip.  Your 99th percentile needs to be under 20ms on the DB storage
> side.  If your worst case DB I/O goes beyond 300ms it is considered an
> outage because the POS transaction fails.  So it obviously takes allot
> of planning and optimization work on the DB itself to get good
> tablespace layout to even get into the realm where you can have that
> predictable of latency with multi-million dollar FC storage frames. 
> 
> One of my goals is to be able to offer this level of I/O service on
> commodity hardware.  Simplify the scope of hardware, reduce the number
> of points of failure, make the systems more portable, reduce or
> eliminate dependence on any specific vendor below the application and
> save money.  Not to mention reduce the number of fingers that can point
> away from themselves saying it is someone elses problem to find fault.
> 
> Allot of the pieces are already out there.  A good block caching target
> is one of the missing pieces to help fill the ever growing canyon
> between non-block device system performance and storage.  What they have
> done with L2ARC and SLOG in ZFS/Solaris is good but it has some serious
> short comings in other areas that DM/MD/LVM do extremely well.
> 
> I appreciate all of the brilliant work all of you guys do and hopefully
> I can contribute a little bit of usefulness to this effort.
> 
> Thank you,
> 
> Jason
> 
> --
> dm-devel mailing list
> dm-devel@...hat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists