koyaanisqatsi

Single-disk performance impact on the array

5 posts in this topic Last Reply

Recommended Posts

Posted (edited)

Hey All,

 

Here's an interesting look at how a single disk's performance affects the entire array.  I ran a parity check on my 6-disk array yesterday, and cacti logged these graphs:

 

1167048183_ArrayPerformance.thumb.png.35800d59ba2d803e577614b4d0dd04b2.png

 

Disks sdc, sdd and sdh are 6 TB WD Reds.

Disks sde and sdf are 2 TB Seagate somethings.

Disk sdg is a 1 TB WD Blue.

 

The "beginning" of a disk performs much better than the "end" of a disk, due to how the data is physically organized on the disk platters.

 

As the parity check progressed across the 1 TB disk, its decrease in performance slowed down the entire array, until the scan reached the end of the 1 TB disk.  Then performance jumped back up, until the scan started slowing down again toward the end of the the 2 TB disks.  Then it jumped back up again while it read through the remaining space on the 6 TB disks.

 

I've known for years that in unRAID, a slow disk would impact performance of the entire array.  And having data that not only confirms the point, but also shows that the array is literally LOCKED to the performance of the slowest disk, is really eye-opening.

 

EDIT: Sorry, this was supposed to be posted in the lounge, please move if necessary.

Edited by koyaanisqatsi
Posted in the wrong forum.

Share this post


Link to post
Posted (edited)

Nice, so I always take out slow disk from array first. I really hope unRAID could overcome those performance issue.

 

 

Edited by Benson

Share this post


Link to post
1 hour ago, koyaanisqatsi said:

I've known for years that in unRAID, a slow disk would impact performance of the entire array.  And having data that not only confirms the point, but also shows that the array is literally LOCKED to the performance of the slowest disk, is really eye-opening.

 

Of course, this is just for parity checks, which isn't the "normal" usage.

 

When reading a file, only the disk the file is on is involved.

 

When writing a file (non-turbo), only the disk being written and the parity disk are involved.

 

When writing a file (turbo), the whole array is involved, but turbo does the parity update differently so there is less disk access required.

Share this post


Link to post

Ah, good point!  I was wondering if what I had seen was the case - which is the only disks that seem to be accessed during a write are the target disk and parity.  Makes sense.

 

I am not aware of turbo. Need to read up on that.

Share this post


Link to post

What can be seen here is that most of the time, the machine was managing 100 MB/s or more. It was actually the larger disks that ended up with the lowest transfer rates at the end.

 

But for most of your storage capacity, you can almost fill the bandwidth of a gbit network interface (about 110 MB/s) when reading a single stream from a disk.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.