limetech Posted November 6, 2009 Author Share Posted November 6, 2009 Now I'm thinking...could have bumped Samba to 3.3.9, stable for quite awhile.. Hopefilly in 4.5.9-final. Yes I should update Samba to that release since there are some fixes for Windows 7. We'll see... Quote Link to comment
limetech Posted November 6, 2009 Author Share Posted November 6, 2009 Yes!!! My 19th data drive works!!! Thanks Tom, Bax Good to hear! Quote Link to comment
limetech Posted November 6, 2009 Author Share Posted November 6, 2009 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'. Quote Link to comment
limetech Posted November 6, 2009 Author Share Posted November 6, 2009 - 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> Quote Link to comment
LVLAaron Posted November 6, 2009 Share Posted November 6, 2009 My cache drive doesn't seem to want to unmount in this release. Quote Link to comment
LVLAaron Posted November 6, 2009 Share Posted November 6, 2009 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 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 Quote Link to comment
limetech Posted November 6, 2009 Author Share Posted November 6, 2009 My cache drive doesn't seem to want to unmount in this release. If you have an open file on the cache drive, or a shell session where the current directory is on the cache drive, it will not un-mount until you rectify that situation - same as previous betas. Quote Link to comment
LVLAaron Posted November 6, 2009 Share Posted November 6, 2009 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? Quote Link to comment
Romir Posted November 7, 2009 Share Posted November 7, 2009 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? Shutdown Sabnzbd if you haven't. Quote Link to comment
WeeboTech Posted November 7, 2009 Share Posted November 7, 2009 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 # Quote Link to comment
LVLAaron Posted November 7, 2009 Share Posted November 7, 2009 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. 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? Quote Link to comment
limetech Posted November 7, 2009 Author Share Posted November 7, 2009 Please post a syslog. You can enter this in your browser address: //tower/log/syslog Then select/copy/paste. Quote Link to comment
bubbaQ Posted November 7, 2009 Share Posted November 7, 2009 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. Quote Link to comment
LVLAaron Posted November 7, 2009 Share Posted November 7, 2009 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? Quote Link to comment
LVLAaron Posted November 7, 2009 Share Posted November 7, 2009 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. Quote Link to comment
vern Posted November 7, 2009 Share Posted November 7, 2009 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. Quote Link to comment
bubbaQ Posted November 7, 2009 Share Posted November 7, 2009 Check the open files: lsof /mnt/cache and this will tell what files python has open on the cache drive Quote Link to comment
LVLAaron Posted November 7, 2009 Share Posted November 7, 2009 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. Quote Link to comment
BRiT Posted November 7, 2009 Share Posted November 7, 2009 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. Quote Link to comment
Rob_Esc Posted November 7, 2009 Share Posted November 7, 2009 ...Seagate ST31000340AS 1TB hard drives with firmware "SD15". Figures. I have six of these in my array Quote Link to comment
DMAddict Posted November 7, 2009 Share Posted November 7, 2009 Just to report that this update still has not increased my write speed. 4.37 GB file took 5:19 to copy. (14 mb average) I guess it's back 4.4.2 until next time. Thanks all the same. Quote Link to comment
david81 Posted November 7, 2009 Share Posted November 7, 2009 300 MB test file in 6.7 seconds, 45MB/s according to TeraCopy. I like. Quote Link to comment
purko Posted November 7, 2009 Share Posted November 7, 2009 Now I'm thinking...could have bumped Samba to 3.3.9, stable for quite awhile.. Hopefilly in 4.5.9-final. Yes I should update Samba to that release since there are some fixes for Windows 7. We'll see... Dare you try 3.4.x? Or is that still too raw? Quote Link to comment
purko Posted November 7, 2009 Share Posted November 7, 2009 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 Quote Link to comment
fitbrit Posted November 7, 2009 Share Posted November 7, 2009 I'm loving this so far. Transferring between disks using MC is showing between 21 to 39 MB/s. I'd usually see 10 to 16 MB/s. Great work, Tom! Quote Link to comment
Recommended Posts
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.