From: Stan Hoeppner <stan@hardwarefreak.com>
To: Jimmy Thrasibule <thrasibule.jimmy@gmail.com>
Cc: Linux RAID <linux-raid@vger.kernel.org>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: ARC-1120 and MD very sloooow
Date: Thu, 28 Nov 2013 13:59:48 -0600 [thread overview]
Message-ID: <5297A0B4.5020303@hardwarefreak.com> (raw)
In-Reply-To: <CAMqSRmCJEp1i9QXGRBZ+2Ohv95=JfTkwO9oTnE3fkX0K1f6hug@mail.gmail.com>
On 11/28/2013 9:59 AM, Jimmy Thrasibule wrote:
>> Right. It's unusual to see this many mount options. FYI, the XFS
>> default is relatime, which is nearly identical to noatime. Specifying
>> noatime won't gain you anything. Do you really need nosuid, nodev, noexec?
>
> Well better say what I don't want on the filesystem no?
>
> >Do you also see the low write speed and slow ls on md0, any/all of your
>> md/RAID10 arrays?
>
> Yes, all drive operations are slow, unfortunately, I have no drives in
> the machine
> that are not managed by the controller to push tests further.
Testing a single drive might provide a useful comparison.
>> The usual: "iostat -x -d -m 5" output while the test is running.
>> Also, you are using buffered IO, so changing it to use direct IO
>> will tell us exactly what the disks are doing when Io is issued.
>> blktrace is your friend here....
>
> I've ran the following:
>
> # dd if=/dev/zero of=/srv/store/video/test.zero bs=512K count=6000
> oflag=direct
> 6000+0 records in
> 6000+0 records out
> 3145728000 bytes (3.1 GB) copied, 179.945 s, 17.5 MB/s
While O_DIRECT writing will give a more accurate picture of the
throughput at the disks, single threaded O_DIRECT is usually not a good
test due to serialization. That said, 17.5MB/s is very slow even for a
single thread.
> # dd if=/srv/store/video/test.zero of=/dev/null iflag=direct
> 6144000+0 records in
> 6144000+0 records out
> 3145728000 bytes (3.1 GB) copied, 984.317 s, 3.2 MB/s
This is useless. Never use O_DIRECT on input with dd. The result will
always be ~20x lower than actual drive throughput.
> Traces are huge for the read test so I put them on Google Drive + SHA1 sums:
> https://drive.google.com/folderview?id=0BxJZG8aWsaMaVWkyQk1ELU5yX2c
>
> Drives `sdc` to `sdf` are part of the RAID10 array. Only drives `sdc` and `sde`
> are used when reading.
>
>> That makes me wonder if the controller and drive write caches have been disabled.
>> That could explain this.
>
> Caching is enabled for the controller but not much information.
>
> > sys info
> The System Information
> ===========================================
> Main Processor : 500MHz
> CPU ICache Size : 32KB
> CPU DCache Size : 32KB
> CPU SCache Size : 0KB
> System Memory : 128MB/333MHz/ECC
> Firmware Version : V1.49 2010-12-02
> BOOT ROM Version : V1.49 2010-12-02
> Serial Number : Y611CAABAR200126
> Controller Name : ARC-1120
> ===========================================
This doesn't tell you if the read/write cache is enabled or disabled.
This is simply the controller information summary.
> By the way is enabling the controller cache a good idea? I would disable
> it and let the kernel manage.
With any decent RAID card the cache is enabled automatically for reads.
The write cache will only be enabled automatically if a battery module
is present and the firmware test shows it is in good condition. Some
controllers allow manually enabling the write cache without battery.
This is usually not advised. Since barriers are enabled in XFS by
default, you may try enabling write cache on the controller to see if
this helps performance. It may not depending on how the controller
handles barriers. And of course, using md you'll want drive caches
enabled or performance will be horrible. Which is why I recommending
checking to make sure they're enabled.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2013-11-28 19:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1385118796.8091.31.camel@bews002.euractiv.com>
2013-11-22 20:17 ` ARC-1120 and MD very sloooow Stan Hoeppner
2013-11-25 8:56 ` Jimmy Thrasibule
2013-11-26 0:45 ` Stan Hoeppner
2013-11-26 2:52 ` Dave Chinner
2013-11-26 3:58 ` Stan Hoeppner
2013-11-26 6:14 ` Dave Chinner
2013-11-26 8:03 ` Stan Hoeppner
2013-11-28 15:59 ` Jimmy Thrasibule
2013-11-28 19:59 ` Stan Hoeppner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5297A0B4.5020303@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=linux-raid@vger.kernel.org \
--cc=thrasibule.jimmy@gmail.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox