Message-ID: <20101226234917.GE18227@bitwizard.nl>
Date:	Mon, 27 Dec 2010 00:49:17 +0100
From:	Rogier Wolff <R.E.Wolff@...Wizard.nl>
To:	Greg Freemyer <greg.freemyer@...il.com>
Cc:	Rogier Wolff <R.E.Wolff@...wizard.nl>,
	Michael Tokarev <mjt@....msk.ru>,
	Krzysztof Halasa <khc@...waw.pl>,
	Bruno Prémont <bonbons@...ux-vserver.org>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: Slow disks.

On Sun, Dec 26, 2010 at 06:17:40PM -0500, Greg Freemyer wrote:
> On Sun, Dec 26, 2010 at 4:40 PM, Rogier Wolff <R.E.Wolff@...wizard.nl> wrote:
> > On Sat, Dec 25, 2010 at 01:14:07PM +0100, Rogier Wolff wrote:
> >> Out of four partitions on the drive, two are aligned, two are not.
> >
> > Ooops. I looked wrong. Sorry. All four partitions are mis aligned.
> >
> >        Roger.
> 
> It sounds like you have 3 or 4 separate issues that are each costing
> you a factor of 3 or so of pain.
> 
> 3 * 3 * 3 *3 = 81  ( I don't recall how bad your overall problem was).
> 
> I can remember:
> 
> Raid 5 - poor choice for 4KB random writes - a factor of 2-4
> Misaligned 4KB physical sectors - a factor of 2+
> Excessive Head Parking  (You show 100K plus head parks in your smart
> data) - (who knows.  It takes a while to un-park the heads and your
> heads are parking way too often.)

Still I think that iostat -x output shows a different story: 

On a different server, I have many many many files. I started a delete
of some of them two days ago. That server is performing just fine. It
shows that disk IOs are serviced on average after around 5-15ms. Those
are normal numbers.

The "remove many files" operation is also likely to cause a similar
small-ios-workload as the mailserver. On the other hand, there are
samsung drives there.

You might be right that we have a few issues together. that might
compound things. But the "30x" performance difference estimate came
from the service time stats from iostat. 

Raid5 might cause us an additional performance hit in real life, but
it does not affect the measured service times of the drives. 

The head parking (and unparking) can indeed influence service times if
say the drive is parking after each IO. On the other hand when the
kernel shows "100% usage" we might hope for the drive not to have time
enough to start thinking about parking the head. And the kernel showed
100% usage through periods as large as ten seconds at a time.

> I think you said it was a 8TB, I know its a pain, but I'd rebuild.  I
> don't know how reliable various large drives are currently.  in
> 2008/2009 they seemed to be horrible and the advice was to use drives
> from different vendors, etc so you would be less likely to have a
> batch of drives go bad all at once.

The Samsungs are holding out really well. I have 8*1T and 4*2T (and a
few 4*1T) running just great. Seagate goofed with some 500Gb and 1T
drive sizes IIRC. You're right you wouldn't want to have two of them
stop/crash at the same time due to the same bug. (chances were around
1% for a 4-drive setup). 

Anyway. Others say that mixing drives is bad because the performance
wouldn't match. At least the performance bottleneck for the array is
the slowest disk, so you'll almost allways end up with worse
performance than when you have all disks the same.



	Roger. 

-- 
** R.E.Wolff@...Wizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists