Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Aug 2013 16:36:26 -0400
From:      J David <j.david.lists@gmail.com>
To:        James Gosnell <jamesgosnell@gmail.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Terrible disk performance with LSI / FreeBSD 9.2-RC1
Message-ID:  <CABXB=RRvp0BLURq7M9iBb5anqaGsrvXeA1WmAroNji6bZP8p4w@mail.gmail.com>
In-Reply-To: <CAEhBLvg7ZUMja5zpFm2UQBXESW-0fL9L7EatR2aasstXd8ALHA@mail.gmail.com>
References:  <CABXB=RSRnB41yjq5Qcbiz-JCRssNwx2AatJ2Dn+HhuD9GaBh+w@mail.gmail.com> <CAEhBLvg7ZUMja5zpFm2UQBXESW-0fL9L7EatR2aasstXd8ALHA@mail.gmail.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Wed, Aug 7, 2013 at 3:15 PM, James Gosnell <jamesgosnell@gmail.com> wrote:
> Maybe one of your drives is bad, so it's constantly doing error correction?

Not according to SMART; all the drives report no problems.  Also, all
the drives seem to perform in lock-step for both reading and writing.
E.g. when one drive in an array is failing, all the drives may be
pulling the same # of reads, but the failing drive will often report
100% busy and/or multi-second svc_t's and the others will sit at 4%
with 20msec svc_t's or similar.  In this case, it's acting like the
disks are all hugely overloaded.   Except without even the high
svc_t's I typically associate with overworking an array.

The speeds do fluctuate.  Last night it was down to 64k/sec reads per
drive (about 15 reads/sec) and still reporting 90% busy on all drives.

It feels like some sort of issue with the
bus/controller/kernel/driver/ZFS that is affecting all the drives
equally.

Also, even ls takes forever (10-30 seconds for "ls -lh /") but when it
eventually does finish, "time ls -lh /" reports:

        0.02 real         0.00 user         0.00 sys

Really not sure what to make of that. An attempt to do "ps axlww |
fgrep ls" while the ls was running failed, because the ps hangs just
as long as the ls.  So it's like the system is just repeatedly putting
anything that touches the disks on hold, even if all the data being
requested is clearly in cache.  (Even apparently loading the binary
for /bin/ls or doing "ls -lh /" twice in a row.)

Thanks!



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?CABXB=RRvp0BLURq7M9iBb5anqaGsrvXeA1WmAroNji6bZP8p4w>