Re: Testing Sandforce SSD - Mailing list pgsql-performance

From Hannu Krosing
Subject Re: Testing Sandforce SSD
Date
Msg-id 1280176849.29137.1366.camel@hvost
Whole thread Raw
In response to Re: Testing Sandforce SSD  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-performance
On Mon, 2010-07-26 at 14:34 -0400, Greg Smith wrote:
> Matthew Wakeling wrote:
> > Yeb also made the point - there are far too many points on that graph
> > to really tell what the average latency is. It'd be instructive to
> > have a few figures, like "only x% of requests took longer than y".
>
> Average latency is the inverse of TPS.  So if the result is, say, 1200
> TPS, that means the average latency is 1 / (1200 transactions/second) =
> 0.83 milliseconds/transaction.

This is probably only true if you run all transactions sequentially in
one connection?

If you run 10 parallel threads and get 1200 sec, the average transaction
time (latency?) is probably closer to 8.3 ms ?

>  The average TPS figure is normally on a
> more useful scale as far as being able to compare them in ways that make
> sense to people.
>
> pgbench-tools derives average, worst-case, and 90th percentile figures
> for latency from the logs.  I have 37MB worth of graphs from a system
> showing how all this typically works for regular hard drives I've been
> given permission to publish; just need to find a place to host it at
> internally and I'll make the whole stack available to the world.  So far
> Yeb's data is showing that a single SSD is competitive with a small
> array on average, but with better worst-case behavior than I'm used to
> seeing.
>
> --
> Greg Smith  2ndQuadrant US  Baltimore, MD
> PostgreSQL Training, Services and Support
> greg@2ndQuadrant.com   www.2ndQuadrant.us
>
>


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



pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Next
From: Lew
Date:
Subject: Re: Big difference in time returned by EXPLAIN ANALYZE SELECT ... AND SELECT ...