30% Read Performance Improvement Tweak... Still works in unRaid 4.2

[Joe L.]

I am assuming you did run the blockdev --setra command on each of their respective /dev/md1, /dev/md2,/dev/md3, etc devices.  If you only ran it on the /dev/md1 device it would only affect the first disk in your array.

 

Is this step something that has to be done separately from the addition to the go script?  OR is the go script addition all that is required?  Clear as mud I hope

You could add the lines to the end of the "go" script AND then reboot the unRaid server so they are then run.

OR

you could add the lines to the end of the "go" script so they will execute each time you reboot, but not reboot at this time.

If you do not reboot to run the commands in the newly added loop in the "go" script, then you need to run the blockdev command individually on each drive, either one at a time,as we've shown in these tests, or by putting those same 5 lines from my original post in a different file, changing its mode, "chmod +x your_file_name" and executing it.

 

Just adding commands to the end of the "go" script does not execute them UNTIL you reboot, then they are executed. So, if nobody is using your server and you are OK for a reboot, add the lines and reboot... it is probably the easiest.

 

If you want to experiment, as we have, and go back and forth with different read-ahead settings, you will need to run the commands individually on the specific drive you are testing as we have shown in our posts.  Either way, you will probably want to add the lines to your "go" script so you don't have to execute them by hand each time you reboot.

 

Joe L.

[flambot]

I am assuming you did run the blockdev --setra command on each of their respective /dev/md1, /dev/md2,/dev/md3, etc devices.  If you only ran it on the /dev/md1 device it would only affect the first disk in your array.

 

Is this step something that has to be done separately from the addition to the go script?  OR is the go script addition all that is required?  Clear as mud I hope

You could add the lines to the end of the "go" script AND then reboot the unRaid server so they are then run.

OR

you could add the lines to the end of the "go" script so they will execute each time you reboot, but not reboot at this time.

If you do not reboot to run the commands in the newly added loop in the "go" script, then you need to run the blockdev command individually on each drive, either one at a time,as we've shown in these tests, or by putting those same 5 lines from my original post in a different file, changing its mode, "chmod +x your_file_name" and executing it.

 

Just adding commands to the end of the "go" script does not execute them UNTIL you reboot, then they are executed. So, if nobody is using your server and you are OK for a reboot, add the lines and reboot... it is probably the easiest.

 

If you want to experiment, as we have, and go back and forth with different read-ahead settings, you will need to run the commands individually on the specific drive you are testing as we have shown in our posts.  Either way, you will probably want to add the lines to your "go" script so you don't have to execute them by hand each time you reboot.

 

Joe L.

 

Thx Joe.  I don't really like to play with the server when it's been running flawlessly for weeks (ever since I sorted a dud drive). 

 

However, I'm willing to have a go if it increases performance - especially as mine is exclusively a media (video) server.  I'll see how I get on.

[Suse User]

This works brilliantly for me!, thanks Joe!

 

Sata or IDE get's a real speed boost.

 

I moved a sample 2gb file from a sata to my PC and repeated from an IDE on the same array to my PC and in both cases I got between 35% to 40% speed improvement!

 

I'm not sure of the transfer rates but my TX/Rcv Performance % went from 21-22% to 38-40%

 

Approx Mbps from 200ish to 280ish

 

Great work!

 

I'm Currently still using 4.0 BTW due to Realtek network issues on beta updates

 

Mark.

[jcato]

This trick works great on my system, too!  Seems to go from about 25 MB/s to about 56 MB/s.  All my drives are IDE (except the partiy drive is SATA).

 

I'm a little confused on one thing, though.  It seems issuing the command blockdev --setra 2048 /dev/md1 sets all drives to 2048.  Here's what the output looked like:

 

root@Tower:~# dd if=/mnt/disk2/Movies/Movie/Movie.avi of=/dev/null
4767764+0 records in
4767764+0 records out
2441095168 bytes (2.4 GB) copied, 97.504 seconds, 25.0 MB/s
root@Tower:~# blockdev --getra /dev/md1
256
root@Tower:~# blockdev --getra /dev/md2
256
root@Tower:~# blockdev --getra /dev/md3
256
root@Tower:~# blockdev --setra 2048 /dev/md1
root@Tower:~# blockdev --getra /dev/md1
2048
root@Tower:~# blockdev --getra /dev/md2
2048
root@Tower:~# blockdev --getra /dev/md3
2048
root@Tower:~# dd if=/mnt/disk2/Movies/Movie/Movie.avi of=/dev/null
4767764+0 records in
4767764+0 records out
2441095168 bytes (2.4 GB) copied, 42.2949 seconds, 57.7 MB/s

 

I am not very linux-savy, but what am I misunderstanding?  Why loop if sitting the first one, sits all them?

 

 

[Joe L.]

This trick works great on my system, too!  Seems to go from about 25 MB/s to about 56 MB/s.  All my drives are IDE (except the partiy drive is SATA).

 

I'm a little confused on one thing, though.  It seems issuing the command blockdev --setra 2048 /dev/md1 sets all drives to 2048.  Here's what the output looked like:

 

root@Tower:~# dd if=/mnt/disk2/Movies/Movie/Movie.avi of=/dev/null
4767764+0 records in
4767764+0 records out
2441095168 bytes (2.4 GB) copied, 97.504 seconds, 25.0 MB/s
root@Tower:~# blockdev --getra /dev/md1
256
root@Tower:~# blockdev --getra /dev/md2
256
root@Tower:~# blockdev --getra /dev/md3
256
root@Tower:~# blockdev --setra 2048 /dev/md1
root@Tower:~# blockdev --getra /dev/md1
2048
root@Tower:~# blockdev --getra /dev/md2
2048
root@Tower:~# blockdev --getra /dev/md3
2048
root@Tower:~# dd if=/mnt/disk2/Movies/Movie/Movie.avi of=/dev/null
4767764+0 records in
4767764+0 records out
2441095168 bytes (2.4 GB) copied, 42.2949 seconds, 57.7 MB/s

 

I am not very linux-savy, but what am I misunderstanding?  Why loop if sitting the first one, sits all them?

 

 

Interesting... I did not know the "md" devices could be set with a single --setra command. 

Perhaps they share a single variable that sets the buffer size. (or perhaps they share a single buffer)

 

In any case, glad the command helps on your system.... even if you only run it on one device 

 

Joe L.

[zzsprade]

Just curious as to why I can not actually see the 'go' file on my flash drive.

 

I have edited the one included in the latest version, but when I go to copy it into the config directory it says that it is there, yet I still can not see it.

 

Hidden files have been enabled.

 

Any ideas?

 

-Alex

[Joe L.]

Just curious as to why I can not actually see the 'go' file on my flash drive.

 

I have edited the one included in the latest version, but when I go to copy it into the config directory it says that it is there, yet I still can not see it.

 

Hidden files have been enabled.

 

Any ideas?

 

-Alex

samba is interpreting the permissions as it being a "protected operating system," file.  Uncheck "hide protected operating system files" in file-explorer, and you should see it.

[zzsprade]

Just curious as to why I can not actually see the 'go' file on my flash drive.

 

I have edited the one included in the latest version, but when I go to copy it into the config directory it says that it is there, yet I still can not see it.

 

Hidden files have been enabled.

 

Any ideas?

 

-Alex

samba is interpreting the permissions as it being a "protected operating system," file.   Uncheck "hide protected operating system files" in file-explorer, and you should see it.

 

Thank you. I will give it a go.

[BLKMGK]

Added to mine and run from commandline to see if any differences can be found\noticed. It's doing a Parity check now which I wouldn't expect this to help but might as well give it a shot ;-)

 

It does seem like just the one set command sets all drives on mine as well.

[Suse User]

Added to mine and run from commandline to see if any differences can be found\noticed. It's doing a Parity check now which I wouldn't expect this to help but might as well give it a shot ;-)

 

It does seem like just the one set command sets all drives on mine as well.

 

Could Joe clarify how this line should now read in the "go" file please?  I would imagine that if all is set from the 1st drive's instruction then the loop would be unnecessarily drive increasing the boot time by issuing the same instruction per drive?

 

Many thanks,

 

Mark.

[Joe L.]

Mark,

 

I don't think you would notice any difference in boot up time since the loop I suggested executes in a fraction of a second.

 

You would still need to add a "sleep" command to ensure the array has been started by the emhttp program.  That is where we waited for 30 seconds before setting the read-ahead buffer.

 

If you still want to experiment, these are the two lines you would add to the end of your "go" script:

 

sleep 30

blockdev --setra 2048 /dev/md1

 

I plan on leaving mine as it is, with the loop, just in case it is set per drive at some point in time.  The fraction of a second extra when re-booting does not bother me, I tend to re-boot the server rarely. (last time for me was about a month ago)

 

Joe L.

[BLKMGK]

I set this from the commandline during a large file transfer, while not a massive difference in transfer speeds I CAN see a difference in the peaks hit by the transfer. Even on machines with SATA drives and 16meg caches this is making a difference IMO. Now if we cold JUST get rid of the troughs in the transfer speed graph we'd be in business! <sigh>

 

Trying to attach animage but 128K is pretty damned tight! Oh well even uner 100K it won't upload <sigh>

[Billped]

I posted a related item elsewhere, though on a 4.0 system ...

 

http://lime-technology.com/forum/index.php?topic=797.msg7824#msg7824

 

I can also confirm that the loop takes near-zero time.  I did at the command line for my five drive system and it was probably 0.1 sec.

 

 

Bill

[boosted]

My test results on a 4.2.1 M2NPV-VM board with all IDE drives. (3) Disk being copied from is a 200GB Seagate .7 with 8MB buffer.

 

1GB file copy from a mapped drive share using onboard IDE controller:

 

before: 71 sec 14.3MB/S

 

After: 43 sec  23.8MB/S  66% improvement!

 

Granted, 23.8MB is pretty pathetic, but it certainly is a lot faster than 14.3MB!!! Fantastic discovery!

 

 

 

*edit*  ok, on a 3GB file transfer, it went abover 45MB/S!  I guess my test needed to be longer to get a better sample.

[goofygrin]

Whatever you do, don't do this to drives that are spun down.

 

Kernel panic + reboot + parity check ensue.

[Billped]

Whatever you do, don't do this to drives that are spun down.

 

Kernel panic + reboot + parity check ensue.

 

Good to know.

 

 

Bill

[Joe L.]

I had to give it a try... I have an all IDE array with 8 data drives currently populated.

 

I first looked at the unnRaid console. All my disks were idle.

 

I then executed the following commands:

 

for i in /dev/md*

> do

> echo $i

> blockdev --setra 2048 $i

> done

/dev/md1

/dev/md2

/dev/md3

/dev/md4

/dev/md5

/dev/md6

/dev/md7

/dev/md8

root@Tower:/#

 

No kernel panic, no reboot, just the root prompt once the command finished. (it ran in less than a second or two) It did not spin up the disks.

 

So... it might be something related to your motherboard or disk controller, but it does not cause a kernel panic here on the original recommended  Intel motherboard and promise disk controller cards when the disks are spun down.  (it does not spin them up either)

 

Joe L.

[goofygrin]

Ya I'm having other issues... I think there's something funky going on in my system.

[goofygrin]

after futzing a bit, I went from ~21m/s to 80+m/s, so that's a huge increase (2.5 gig nuv file).

[Billped]

after futzing a bit, I went from ~21m/s to 80+m/s, so that's a huge increase (2.5 gig nuv file).

 

Doing what?  Read?  Write?  Parity?  Also, I assume this is MB/sec, not Mb/sec, right?

 

And what futzing did you do?

 

 

Bill

[goofygrin]

after futzing a bit, I went from ~21m/s to 80+m/s, so that's a huge increase (2.5 gig nuv file).

 

Doing what?  Read?  Write?  Parity?  Also, I assume this is MB/sec, not Mb/sec, right?

 

And what futzing did you do?

 

 

Bill

 

I'd been having stability issues, so I've been playing with different versions of unRAID.  I'd been stable for about a year on 4.0b10, but recently added some new drives and upgraded to 4.2.1 with a Pro license.  Things got really unstable.

 

On 4.2.1 I went from about 25/sec (MB or whatever dd reports) to about 45-50.  When I rolled back to 4.0, I made the jump to 80+/sec with this change.  This is doing the same dd to /dev/null that the OP used to test it with.  SATA drives copying a 2+gig HD recording.

 

I've also not had any issues *yet* but I think they might have been related to a bad format since the error I was getting was related to a reiser format thing.

[mikester]

I tried this tonight - didn't seem to help (although I can't complain to begin with).  This is on Unraid 4.0 with a 500GB SATA drive with 16MB cache.

 

root@Tower:~# blockdev --getra /dev/md3
256
root@Tower:~# dd if='/mnt/disk3/DVD/Apollo 13/apollo13.iso' of=/dev/null
14701724+0 records in
14701724+0 records out
7527282688 bytes (7.5 GB) copied, 91.4494 seconds, 82.3 MB/s
root@Tower:~# blockdev --setra 2048 /dev/md3
root@Tower:~# dd if='/mnt/disk3/DVD/Apollo 13/apollo13.iso' of=/dev/null
14701724+0 records in
14701724+0 records out
7527282688 bytes (7.5 GB) copied, 90.8642 seconds, 82.8 MB/s

[cmhardwick]

you were already running at over 80MB/s? SWEET!!! 

[NLS]

What kind of IMPROVEMENT did you expect over that!?

 

 

[mikester]

What kind of IMPROVEMENT did you expect over that!?

 

I didn't know I was running that fast to begin with. 

 

For anyone interested, this is on an Abit AB9 Pro with a 3 GHz Celeron and 1 GB of RAM.  This is a sweet motherboard - 9 onboard SATA2 ports plus 1 external eSata port.  I'm currently running a Seagate 7200.10 500GB SATA2 drive for the parity, and 5 Western Digital 500GB SATA2 drives for data.  The drives are spread out between the 3 separate onboard SATA controllers.