[ale] Performance issue

[Jim Kinney]

6Gbps SAS. 12 in one array and 38 in another. It should saturate the bus.

On Aug 20, 2016 8:41 PM, "DJ-Pfulio" <DJPfulio at jdpfu.com> wrote:

> Bus specifications have little to do with spinning disk performance, as
> you know.
>
> What is the max for each drive to read?  120-180Mbps?  How are the
> arrays striped?  4-way, 8-way?  That would mean at 4 x 120Mbps (480Mbps)
> is the highest possible throughput I'd expect. 960Mbps if 8-way stripe
> ... there is overhead ... so 800Mbps seems reasonable to me.
>
> http://wintelguy.com/raidperf.pl is more pessimistic on performance. I'm
> not convinced this numbers are MB/s. Think they are Mb/s.
>
> On 08/20/2016 06:49 PM, Ted W. wrote:
> > If you didn't already, try either iostat as `iostat -xm 1` or `sar -d`.
> > You see any unusual await or anything else that sticks out?
> >
> > What FS? LVM?
> >
> > A shot in the dark might lead me to check the FS alignment with fdisk
> but that
> > seems like an awfully large performance hit for something like that.
> >
> > -Ted
> >
> > On Fri, Aug 19, 2016 at 10:26:22AM -0400, Jim Kinney wrote:
> >>    Getting DISMAL performance from new hardware.
> >>
> >>    Twin 6-core Xeon E5-2630L v.2 @2.40 GHz
> >>    128GB DDR4 RAM
> >>    LSI megaraid 2108 in a PCIe v3 slot
> >>    Onboard LSI 3108
> >>    Drives are all 6Gbps SAS2 4TB
> >>    2 arrays, RAID 6, one is 40Tb, other 104TB
> >>
> >>    Everything hardware says I should expect a minimum through put of
> >>    12Gbps on either array.
> >>
> >>    The max I'm getting from iotop is 784 Mbps.
> >>
> >>    W. T. F!!!
> >>
> >>    According to top, the system is basically idle. Ditto from iostat and
> >>    every other tool I check. I'm doing a 'cp -a' from/to same array.
> >>
> >>    Yes. New location is Luks encrypted. That process is totally asleep
> >>    it's getting so little work. The rng is busy (dev/random is not
> running
> >>    out (watch -n 1 cat /proc/sys/kernel/random/entropy_avail was always
> >>    above 2048)) but not overloaded or asleep.
> >>
> >>    Tested going unencrypted to unencrypted with similar performance.
> >>
> >>    Changed tuned-adm to latency-performance from balanced and the read
> >>    portion of the cp went to 0 bps for 20 seconds until I switched it
> back
> >>    to balanced mode. So that was a fail. It improved greatly using
> >>    throughout-performance mode (bursts of 250MB/s) but was still showing
> >>    long periods of 0 writes. Load went up from a paltry 8 to 22 so it's
> >>    working more.
> >>
> >>    But top shows wa values across multiple cores hitting 100 so it's
> >>    hitting a wall somewhere.
> >>
> >>    Any ideas of more places to look?
> >
> >> _______________________________________________
> >> Ale mailing list
> >> Ale at ale.org
> >> http://mail.ale.org/mailman/listinfo/ale
> >> See JOBS, ANNOUNCE and SCHOOLS lists at
> >> http://mail.ale.org/mailman/listinfo
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> >
>
>
> --
> Got Linux? Used on smartphones, tablets, desktop computers, media
> centers, and servers by kids, Moms, Dads, grandparents and IT
> professionals.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20160820/c6eb7500/attachment.html>