lkml.org 
[lkml]   [2013]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [dm-devel] Announcement: STEC EnhanceIO SSD caching software for Linux kernel

    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


    \
     
     \ /
      Last update: 2013-01-18 20:22    [W:4.151 / U:0.500 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site