On 7/18/2012 2:22 AM, Stefan Ring wrote:
> Because it was XFS originally which hammered the controller with this
> disadvantageous pattern.
Do you feel you have researched and tested this theory thoroughly enough
to draw such a conclusion? Note the LSI numbers with a single thread
compared to the P400. It seems at this point the LSI has no problem
with the pattern. How about threaded results?
> Except for the concurrency, it doesn't matter
> much on which filesystem sysbench operates. I've previously verified
> this on another system.
It's hard to believe a 4 generation old (6-7 years) LSI ASIC with
256/512MB cache is able to sink this workload without ever stalling when
flushing to rust, where the HP P2000 FC SAN array shows pretty sad
performance. I'd really like to see the threaded results for the LSI at
this point. I think that would be informative.
> It was the Fibre Channel controller, the one with the collapsing
> throughput. (P2000 G3 MSA, QLogic Corp. ISP2532-based 8Gb Fibre
> Channel to PCI Express HBA)
Given the LSI 1078 based RAID card with 1 thread runs circles around the
P2000 with 4, 8, or 16 threads, and never stalls, with responses less
than 1ms, meaning all writes hit cache, it would seem other workloads
are hitting the P2000 simultaneously with your test, limiting your
performance. Either that or some kind of quotas have been set on the
LUNs to prevent one host from saturating the controllers. Or both.
This is why I asked about exclusive access. Without it your results for
the P2000 are literally worthless. Lacking complete configuration info
puts you in the same boat. You simply can't draw any realistic
conclusions about the P2000 performance without having complete control
of the device for dedicated testing purposes.
You have such control of the P400 and LSI do you not? Concentrate your
testing and comparisons on those.