unRAID Server release 4.5-beta8 available


limetech

Recommended Posts

  • Replies 144
  • Created
  • Last Reply

Top Posters In This Topic

Very exciting release!!!  But hope everyone remembers this is BETA, and these are some new features for unRAID.

 

If you have a test array or are the adventuresome type, install beta8, test it thoroughly, and let the rest of the community know your experiences.  If you are running a large important (to you) array, you might want to wait for others to check Beta8 thoroughly before taking the plunge.

 

Suggested tests ...

- Experiement with the new settings to determine best performance settings

- Copy some large files back and forth and use md5 to confirm they copied correctly

- Run a parity check and make sure it works

- Experiment with different drives, different manufacturers, and firmware levels

- Determine if video stuttering occurs while copying data to the array

- Carefully review the syslog for any unusual errors after "stressful" activity

- Confirm compatibility with unmenu, directory cache, powerdown, and other community developed tools you use

 

 

Very good advice.  Especially interested in cases of 'video stuttering'.

Link to comment

- Increased write performance and added three user-tunables:

   md_num_stripes to set the stripe cache size

   md_write_limit to set a ceiling on most number of active write stripes

   md_sync_window to set the parity sync/check window size in stripes

 

noob question. How do I activated these? I don't have a cache drive (yet), so 'md_write_limit' and 'md_sync_window' only apply for me, right? What is a good value to set these at?

 

Many thanks, I'm still learning and having fun.

 

Edit: Both my Seagate 500GiG drives are:

Model Number:       ST3500641AS                             

Firmware Revision:  3.AAD

 

None of these tunables have anything to do with the Cache Drive; they are 'tweaks' for the low-level unraid array driver only.

 

First, you can create a file in the 'config' directory of the Flash called 'extra.cfg'.  This file is read when the array is Started and may be used to define the values (or override default values) of these tunables.  Here are the current defaults:

 

md_num_stripes=1280

md_write_limit=768

md_sync_window=288

 

md_num_stripes defines the maximum number of active 'stripes' the driver can maintain.  You can think of a 'stripe' as a 4K I/O request.  For example, let's say you are reading a large (many megabytes) file from the server.  Well the driver will "see" a series of (largely) sequential 4K read requests.  The driver will determine which disk the read is for and then pass that 4K read request to the disk driver.  Well the most such requests would be 1280.  If there are 1280 requests already active and another request comes in, then the process making that request has to wait until a stripe become free (as a result of previous I/O finishing).

 

Bottom line is this: the greater this number is, the more I/O can be queued down into the disk drives.  However each 'stripe' requires memory in the amount of (4096 x highest disk number in array).  So if you have 20 disks, each stripe will require 81920 bytes of memory; multiplied by 1280 = over 104MB.  The default value was chosen to maximize performance in systems with only 512MB of RAM.  If you have more RAM then you can experiment with higher values.  If you go too high and the system starts running out of memory, what will happen is 'random' processes will start getting killed (not good).

 

md_write_limit specifies the maximum number of stripes which will be used for write.  This is because if you starting writing a large file, there can easily be 'md_num_stripes' requests immediately queued.  This will cause reads to different disks to suffer greatly.  So you want to pick a number here that is large but which also leaves some stripes available for reads.  You will find there is a point of diminishing returns.  If you set the number low, say 32, then writes will be very slow.  If you leave it at default, writes will be much faster.  If you set it to say 1000, writes will be a "little bit" faster.  By increasing both md_num_stripes and md_write_limit you might get 10% more performance than default values.  The best you can get is going to be something less than 50% the raw speed of the disk - if you get above 33% let me know :)

 

md_sync_window specifies the most number of parity-sync stripes active during a parity-sync or parity-check operation.  Again, the larger this number, the faster parity-sync will run, with diminishing returns at some point (due mainly to saturating PCI and/or PCIe buses).

 

You want to make sure the sum of md_write_limit+md_sync_window < md_num_stripes so that reads do not get starved if you starting writing a large file while a parity-sync/check is in process.

 

Hopefully I will be able to write up a more thorough document on this subject along with some of theory behind it.

 

Note: if you change the values of these tunables via the 'extra.cfg' file, you must Stop the array, then Start the array for the values to take effect.  The md_write_limit and md_sync_window may be dynamically changed by typing these commands in a telnet session:

 

mdcmd set md_write_limit <value>

mdcmd set md_sync_window <value>

 

Link to comment

This release does have a tremendous  increase in write speed!

 

I have gone from being able to write about 10-12mb a second to ~19/20

 

oQNuX.png

 

Not to mention that in the beta7 release, writing was in chunks...so it would stop every so often essentially averaging write thoughput of about 8 megabytes a second. YUCK.

 

See this thread for an example and updates.

http://lime-technology.com/forum/index.php?topic=4586

Link to comment

It's never been an issue for me. I just turned my system on and the drive will not spindown.

 

Is there a way to tell what files may be open on it?

 

use fuser

Just use it for what drive you want to check.

 

example on my system

 

root@Atlas /etc/rc.d #fuser -cu /mnt/disk1

/mnt/disk1:           6327c(root) 17607c(root) 25407ce(root) 28489ce(root)

root@Atlas /etc/rc.d #ps -fp 28489

UID        PID  PPID  C STIME TTY          TIME CMD

root     28489 17607  0 Oct21 pts/6    00:18:58 /mnt/disk1/bittorrent/bin/rtorrent-0.8.5 -n -o import=/boot/custom/etc/rTorrent.rc

root@Atlas /etc/rc.d #

Link to comment

root@Tower:~# fuser -cu /mnt/cache/
/mnt/cache/:          1812(root)
root@Tower:~#

 

 

That's what I've got for my cache drive. I've never gotten SAB to auto start, so that's not the issue.  :P

 

Anyway, it's not powering down that disk and has trouble stopping the array. I can "Spin Down" and the cache disk will stop in a few seconds.

 

Should I start a new thread?

 

 

 

Link to comment

Add a -v for verbose mode.

 

fuser -cuv /mnt/cache/

 

 

Output from "fuser -cu  /mnt/cache/"

 

/mnt/cache/:          5795c(root)

 

 

Output from "fuser -cuv  /mnt/cache/"

                     USER        PID ACCESS COMMAND
/mnt/cache/:         root       5795 ..c.. (root)nzbget

 

 

Or us ps to get info on the process:

 

ps -f 1812

 

and that will tell you what you need to stop.

Link to comment

Looks like python is doing something.

 

root@Tower:~# fuser -cuv /mnt/cache/

                     USER        PID ACCESS COMMAND
/mnt/cache/:         root       1804 F.... (root)python

 

 

This is my "go" file

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp &



#Install packages and copy files for Sabnzbd
installpkg /boot/packages/python-2.5.2-i486-4.tgz
installpkg /boot/packages/infozip-5.52-i486-2.tgz
installpkg /boot//packages/unrar-3.7.8-i486-1stc_slack12.1.tgz
cp -r /boot/packages/Cheetah /usr/lib/python2.5/site-packages
cp /boot/packages/Cheetah/Cheetah-2.0.1-py2.5.egg-info /usr/lib/python2.5/
cp /boot/packages/Cheetah/bin/cheetah /usr/bin
cp /boot/packages/Cheetah/bin/cheetah-compile /usr/bin
cp -r /boot/packages/OpenSSL /usr/lib/python2.5/site-packages
cp /boot/packages/OpenSSL/pyOpenSSL-0.8-py2.5.egg-info /usr/lib/python2.5/
cp /boot/packages/sabnzbd/par2 /usr/bin
cp /boot/packages/sabnzbd/libtbb* /usr/bin
cp /boot/packages/libstdc++.so* /usr/lib

#Install Feedparser & start SABnzbd
cd /boot/packages/feedparser-4.1
python /boot/packages/feedparser-4.1/setup.py install
python /boot/packages/SABnzbd/SABnzbd.py -d 

 

 

 

I used the exact same config for beta7. The last line of the go file has never worked. SAB doesn't launch through that script. Don't know why. Not for this thread. With beta7 the disk would spin down if SAB was closed, since SAB writes some files every now and then to it's special holding places, which I have on the cache disk. Could this have something to do with the newer kernel?

 

Link to comment

I would like to note that I don't really care if the disk never spins down because I'm running SAB. It's just one disk and I dont want to have to manually start and stop the process just for that one disk to save me 5 watts of electricity. I just want to know exactly WHY it doesn't, as I'm sure the developers would like to know too.

Link to comment

I just wanted to report that I loaded b8 and have also seen a remarkable improvement in the write speed. I was getting ~10 to ~12 MB/sec and now I'm getting ~26 MB/sec. The rate appears to be more consistent as well. I have noticed one thing, the "Refresh" button on the http://unraid:8080/unraid_main (unMenu) page doesn't work for me. If I got to the original page, http://unraid/main.htm, it works fine. I did a fresh reboot and started and stopped unMenu with the same results. I have attached my syslog after a fresh reboot, so maybe there is something in there.

Link to comment

Tower login: root
Linux 2.6.31.5-unRAID.
root@Tower:~# fuser -cuv /mnt/cache/

                     USER        PID ACCESS COMMAND
/mnt/cache/:         root       1819 F.... (root)python

root@Tower:~# lsof  /mnt/cache
COMMAND  PID USER   FD   TYPE DEVICE    SIZE NODE NAME
python  1819 root    1u   REG    8,1    2144    9 /mnt/cache/.nzb/logs/sabnzbd.error.log
python  1819 root    2u   REG    8,1    2144    9 /mnt/cache/.nzb/logs/sabnzbd.error.log
python  1819 root    3w   REG    8,1 3851473   27 /mnt/cache/.nzb/logs/sabnzbd.log
python  1819 root    4u   REG    8,1    2144    9 /mnt/cache/.nzb/logs/sabnzbd.error.log

 

 

It looks like SABnzbd DOES start, but possibly not completely from the go script. I did a ps -ax and found it:

1819 ?        Sl     0:00 python /boot/packages/SABnzbd/SABnzbd.py -d

 

But the webserver part of SAB never runs. I can take it from here. I'll either put a pause in the script and try to get it to start a little later, or just take it out completely.

Link to comment

Exceptional work Limetech / Tom! Just as I was looking forward to a weekend with few projects to do. There's quite a bit for me to do now.

 

I do have a question about the Samba version used on base unRAID. I'm looking to quickly try out the 3.3.x series. Assuming CUPS/HPLP is installed, does it support printing via CUPS? I know the unRAID SAMBA config files says it doesn't do printing, but if the needed settings are added, would it function? On my Slackware setup, I had to downgrade from 3.4.2 version to 3.2.15 version because it broke printing from Win7.

 

EDITED: I notice they now have 3.4.3 and 3.3.9 out which include Win7 fixes.

Link to comment
I will be releasing -beta8 which has, among other things, these two changes:

- set default scheduler to 'cfq'

Looks like for some reason CFQ did not make it in beta8. It still ships with NOOP as default.

 

So I did some serious testing on my server with the new beta. (copying ~20GB folders with DVD files to the server over samba).

It turns out that by just changing the scheduler to CFQ my write speeds increase by about 20%. Repeated reproduceable results.

 

(Note: My server may not be representative for the average unRAID build: It has a Ultra-Low-Voltage 1GHz Mobile processor, without L2 cache, and only 1GB RAM)

 

As for max_sectors_kb - well this just sets the upper limit on an I/O request to a block device (ie, disk drive).  The default value of '512' means that the largest request the disk driver will get is 512KB (or 1024 sectors).  The largest it "should" see is generally 128K.  I don't see how lowering this to 64 would help performance...

 

No, I did not say 64.  I am setting this to precisely 128K.

And I didn't say that it helps performance.  It helps the overall responsiveness of the server.

 

Anything over 128 is killing my tiny little CPU: copying stuff starts to time-out and abort, processes start getting stuck in disk-wait state, and the server starts freezing for long periods of time -- can't even telnet to it.

 

Again, this behavior may only be typical for my particular configuration.

 

Yours,

Purko

 

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.