Everything posted by scottc
-
[Support] Linuxserver.io - Radarr
You can update from within radarr. Goto System -> Updates and update to the latest version.
-
[SOLVED] How to stop Mover
Couldn't you change the mover settings to run something like monthly or weekly? then it would not be moving stuff as often
-
[support] gfjardim's Docker Repository
Yup, Latest update fixed the issue for me also Does this mean that there haw been an additional CrashPlan update since and that the 2nd fix took care of whatever the issue was in the first fix, or does it mean that it took 2 installs of the first (and only recent) fix to make it work? Also, what's been fixed/updated? I'm only 48GB into a 1TB photo backup, and it took several days for CP to settle itself down and actually start making progress. I don't want to kill off the backup if it's for something minor that won't really impact me. Many, many thanks to gfjardim for getting this docker working in the first place! There is an update to the CP docker and the update to the docker should not affect what you have already uploaded. when CP starts it should scan what has already been uploaded and start where it left off
-
[support] gfjardim's Docker Repository
I just updated by Crashplan Docker and I'm having the same problem. I have the same problem. Just updated CP and VNC connection is not working and CP client also can't connect to server. Try to update again. That solved it for me. Sent from my SGP771 using Tapatalk Yup, Latest update fixed the issue for me also
-
[support] gfjardim's Docker Repository
Just updated the crashplan docker and it is not starting. This is what the logs show over and over Sat Oct 1 14:16:32 2016 vncext: VNC extension running! vncext: Listening for VNC connections on all interface(s), port 4239 vncext: created VNC server for screen 0 XKB: Failed to compile keymap Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. Fatal server error: Failed to activate core devices. Openbox-Message: Failed to open the display from the DISPLAY environment variable. Must have netstat installed _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/Tower:1 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root Xvnc TigerVNC 1.7.0 - built Sep 8 2016 10:39:22 Copyright (C) 1999-2016 TigerVNC Team and many others (see README.txt) See http://www.tigervnc.org for information on TigerVNC. Underlying X server release 11400000, The X.Org Foundation Initializing built-in extension VNC-EXTENSION Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension GLX Sat Oct 1 14:16:34 2016 vncext: VNC extension running! vncext: Listening for VNC connections on all interface(s), port 4239 vncext: created VNC server for screen 0 XKB: Failed to compile keymap Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. Fatal server error: Failed to activate core devices. Openbox-Message: Failed to open the display from the DISPLAY environment variable. Must have netstat installed _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/Tower:1 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root Xvnc TigerVNC 1.7.0 - built Sep 8 2016 10:39:22 Copyright (C) 1999-2016 TigerVNC Team and many others (see README.txt) See http://www.tigervnc.org for information on TigerVNC. Underlying X server release 11400000, The X.Org Foundation Initializing built-in extension VNC-EXTENSION Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension GLX
-
[Support] Linuxserver.io - Sonarr
That was my only good idea Unless it is running a task my Sonarr docker uses hardly any resources
-
[Support] Linuxserver.io - Sonarr
No one else is seeing this? I've tried reinstalling the docker, both importing the backup and creating it all new from scratch. Attached is a screenshot from CA showing it at 37% CPU utilization and using 19GB RAM. Not seeing this behaviour at all on my setup. Log into the webgui for sonarr and check System>Tasks, see if there is anything running? Never really had the time to fully investigate, but I don't actually believe that sonarr is truly using that amount of memory. Rather its all the cache, etc that the linux base is using (http://www.linuxatemyram.com/) and it will get released once something else requires the memory. But if you truly are worried about it then limit the amount of RAM that sonarr is capable of using (http://lime-technology.com/forum/index.php?topic=40937.msg492112#msg492112) As far as the CPU usage, I've never really seen sonarr be a pig like that unless its actually scanning or actively searching or what not. You can also limit its CPU resources (http://lime-technology.com/forum/index.php?topic=40937.msg492111#msg492111) for when something else requires the cpu time. The key question is sonarr actually working for you? Yeah, it does seem to be working. That said it's worked fine for months with zero issues, but now in the past few weeks this CPU and RAM thing has started. I could limit the Docker's access to CPU and RAM per your suggestion, but would prefer to find the underlying cause. Are you using the stable ( master ) or development ( develop ) branch? I know there was an issue with the development branch that caused me to have to revert back to master, it would get stuck in a loop of constantly running the refresh series task, it would never fully complete & I ended up with over 20 refresh series tasks running and it was draining my system resources. As soon as I switched it to use the master branch instead of develop branch it completely mellowed out
-
unraid-tunables-tester.sh - A New Utility to Optimize unRAID md_* Tunables
Yay, the first Normal Auto! Unfortunately, really bad results (I trimmed them out above, these posts are getting too long for the forum character limit). There is a ton of randomness here, it didn't settle down at all. Even worse, look at this: Test | num_stripes | sync_window | nr_requests | sync_thresh | Speed --------------------------------------------------------------------------- 1 | 1536 | 768 | 128 | 767 | 110.5 MB/s <-- nr_requests test pass 1, 10 minutes ----------------------------------------------------------------------------- 1 | 1536 | 768 | 128 | 767 | 112.2 MB/s <-- nr_requests test pass 2, 10 minutes Test | RAM | num_stripes | sync_window | nr_reqs | sync_thresh | Speed ----------------------------------------------------------------------------- 7a | 81 | 1536 | 768 | 128 | 767 | 239.0 MB/s <-- md_sync_window test pass 1, 5 minutes --------------------------------------------------------------------------- 17a | 81 | 1536 | 768 | 128 | 767 | 89.8 MB/s <-- md_sync_window test pass 2, 5 minutes The exact same test happened to get run 4 times, with wildly varying results. I can't even begin to understand how that 239 MB/s result got in there, it's just so different, and high. 5 minutes at 239 MB/s is about 70 GB of data processed. Can't imagine this is caching. You also posted earlier you were having power issues to your cages. Any chance the power went out just long enough to let one test parity check run without the slow drives? This is actually my best guess at how this could have happened, but I would have expected lots of issues (redballs) if this occurred. Did you notice any errors at all during the test? They wouldn't be in the report file, just on the screen. If that had been a Short Auto, I wouldn't be surprised. But this being a Normal Auto, I'm not sure what to make of this. Those top two tests I listed were from the nr_requests tests 1 and 2, and those run for 10 minutes instead of 5, and they "might" have produced more consistent results (or maybe that's just a coincidence). Those bottom two tests were from Pass 1 and 2 of the md_sync_window tests, which "only" ran for 5 minutes. Perhaps that's not long enough for your server to settle down. Anyone have any ideas? Long Auto is a big time commitment, and I'm not ready to recommend that just yet. If you are willing, I would recommend you run a Manual test, Start at 768, End at 768, any interval, with a time of 20 minutes. Repeat 1 more time. Because it will pre-run the 4 nr_requests, doing this will take 100 minutes each time, so if you do this twice you're looking at almost 3.5 hours of testing. What I'm looking for is: Does the server settle down with longer tests? (hopefully 20 minutes will tell us), and by running the same values I listed above, we can compare 20 minute tests back to 10 and 5 minute tests. But if you are still having power issues, please resolve those first. Thanks, Paul I am going to be running to best buy today to get some new power module cables and just replace them to all the cages ( completely solve any power issues I may be having ). then I will run the Manual tests and see what happens
-
unraid-tunables-tester.sh - A New Utility to Optimize unRAID md_* Tunables
Here are the results of Normal Automatic Test i let run overnight unRAID Tunables Tester v4.0b2 by Pauven (for unRAID v6.2) Tunables Report produced Wed Aug 24 20:11:00 EDT 2016 Run on server: Tower Normal Automatic Parity Sync Test NOTE: Use the smallest set of values that produce good results. Larger values increase server memory use, and may cause stability issues with unRAID, especially if you have any add-ons or plug-ins installed. Current Values: md_num_stripes=6144, md_sync_window=2768, md_sync_thresh=192 Global nr_requests=128 sdb nr_requests=128 sdc nr_requests=128 sdi nr_requests=128 sdn nr_requests=128 sdh nr_requests=128 sdl nr_requests=128 sdk nr_requests=128 sdj nr_requests=128 sdo nr_requests=128 sdp nr_requests=128 sdq nr_requests=128 sdm nr_requests=128 --- INITIAL BASELINE TEST OF CURRENT VALUES (1 Sample Point @ 5min Duration)--- Test | RAM | num_stripes | sync_window | nr_reqs | sync_thresh | Speed ----------------------------------------------------------------------------- 1 | 327 | 6144 | 2768 | 128 | 192 | 113.0 MB/s --- FULLY AUTOMATIC nr_requests TEST 1 (4 Sample Points @ 10min Duration)--- Test | num_stripes | sync_window | nr_requests | sync_thresh | Speed --------------------------------------------------------------------------- 1 | 1536 | 768 | 128 | 767 | 110.5 MB/s 2 | 1536 | 768 | 128 | 384 | 109.6 MB/s 3 | 1536 | 768 | 8 | 767 | 109.5 MB/s 4 | 1536 | 768 | 8 | 384 | 107.7 MB/s Fastest vals were nr_reqs=128 and sync_thresh=99% of sync_window at 110.5 MB/s This nr_requests value will be used for the next test. --- FULLY AUTOMATIC TEST PASS 1a (Rough - 13 Sample Points @ 5min Duration)--- Test | RAM | num_stripes | sync_window | nr_reqs | sync_thresh | Speed ----------------------------------------------------------------------------- 1a | 40 | 768 | 384 | 128 | 383 | 102.5 MB/s 1b | 40 | 768 | 384 | 128 | 192 | 102.9 MB/s 2a | 47 | 896 | 448 | 128 | 447 | 98.4 MB/s 2b | 47 | 896 | 448 | 128 | 224 | 95.8 MB/s 3a | 54 | 1024 | 512 | 128 | 511 | 103.3 MB/s 3b | 54 | 1024 | 512 | 128 | 256 | 109.4 MB/s 4a | 61 | 1152 | 576 | 128 | 575 | 103.0 MB/s 4b | 61 | 1152 | 576 | 128 | 288 | 106.0 MB/s 5a | 68 | 1280 | 640 | 128 | 639 | 108.8 MB/s 5b | 68 | 1280 | 640 | 128 | 320 | 109.5 MB/s 6a | 75 | 1408 | 704 | 128 | 703 | 105.1 MB/s 6b | 75 | 1408 | 704 | 128 | 352 | 99.5 MB/s 7a | 81 | 1536 | 768 | 128 | 767 | 239.0 MB/s 7b | 81 | 1536 | 768 | 128 | 384 | 109.9 MB/s 8a | 88 | 1664 | 832 | 128 | 831 | 110.5 MB/s 8b | 88 | 1664 | 832 | 128 | 416 | 107.1 MB/s 9a | 95 | 1792 | 896 | 128 | 895 | 109.5 MB/s 9b | 95 | 1792 | 896 | 128 | 448 | 111.8 MB/s 10a | 102 | 1920 | 960 | 128 | 959 | 112.1 MB/s 10b | 102 | 1920 | 960 | 128 | 480 | 113.7 MB/s 11a | 109 | 2048 | 1024 | 128 | 1023 | 106.7 MB/s 11b | 109 | 2048 | 1024 | 128 | 512 | 109.1 MB/s 12a | 115 | 2176 | 1088 | 128 | 1087 | 113.8 MB/s 12b | 115 | 2176 | 1088 | 128 | 544 | 111.7 MB/s 13a | 122 | 2304 | 1152 | 128 | 1151 | 113.2 MB/s 13b | 122 | 2304 | 1152 | 128 | 576 | 104.5 MB/s --- Targeting Fastest Result of md_sync_window 768 bytes for Final Pass --- --- FULLY AUTOMATIC nr_requests TEST 2 (4 Sample Points @ 10min Duration)--- Test | num_stripes | sync_window | nr_requests | sync_thresh | Speed --------------------------------------------------------------------------- 1 | 1536 | 768 | 128 | 767 | 112.2 MB/s 2 | 1536 | 768 | 128 | 384 | 111.4 MB/s 3 | 1536 | 768 | 8 | 767 | 110.1 MB/s 4 | 1536 | 768 | 8 | 384 | 110.0 MB/s Fastest vals were nr_reqs=128 and sync_thresh=99% of sync_window at 112.2 MB/s This nr_requests value will be used for the next test. --- FULLY AUTOMATIC TEST PASS 2 (Fine - 33 Sample Points @ 5min Duration)--- Test | RAM | num_stripes | sync_window | nr_reqs | sync_thresh | Speed ----------------------------------------------------------------------------- 1a | 68 | 1280 | 640 | 128 | 639 | 111.4 MB/s 1b | 68 | 1280 | 640 | 128 | 320 | 112.4 MB/s 2a | 69 | 1296 | 648 | 128 | 647 | 107.0 MB/s 2b | 69 | 1296 | 648 | 128 | 324 | 109.7 MB/s 3a | 69 | 1312 | 656 | 128 | 655 | 114.4 MB/s 3b | 69 | 1312 | 656 | 128 | 328 | 109.8 MB/s 4a | 70 | 1328 | 664 | 128 | 663 | 113.9 MB/s 4b | 70 | 1328 | 664 | 128 | 332 | 113.6 MB/s 5a | 71 | 1344 | 672 | 128 | 671 | 111.8 MB/s 5b | 71 | 1344 | 672 | 128 | 336 | 113.0 MB/s 6a | 72 | 1360 | 680 | 128 | 679 | 111.9 MB/s 6b | 72 | 1360 | 680 | 128 | 340 | 113.3 MB/s 7a | 73 | 1376 | 688 | 128 | 687 | 110.2 MB/s 7b | 73 | 1376 | 688 | 128 | 344 | 110.1 MB/s 8a | 74 | 1392 | 696 | 128 | 695 | 113.7 MB/s 8b | 74 | 1392 | 696 | 128 | 348 | 112.2 MB/s 9a | 75 | 1408 | 704 | 128 | 703 | 112.6 MB/s 9b | 75 | 1408 | 704 | 128 | 352 | 113.1 MB/s 10a | 75 | 1424 | 712 | 128 | 711 | 111.6 MB/s 10b | 75 | 1424 | 712 | 128 | 356 | 113.7 MB/s 11a | 76 | 1440 | 720 | 128 | 719 | 113.6 MB/s 11b | 76 | 1440 | 720 | 128 | 360 | 109.9 MB/s 12a | 77 | 1456 | 728 | 128 | 727 | 92.1 MB/s 12b | 77 | 1456 | 728 | 128 | 364 | 80.6 MB/s 13a | 78 | 1472 | 736 | 128 | 735 | 84.4 MB/s 13b | 78 | 1472 | 736 | 128 | 368 | 70.8 MB/s 14a | 79 | 1488 | 744 | 128 | 743 | 82.7 MB/s 14b | 79 | 1488 | 744 | 128 | 372 | 81.6 MB/s 15a | 80 | 1504 | 752 | 128 | 751 | 95.0 MB/s 15b | 80 | 1504 | 752 | 128 | 376 | 81.5 MB/s 16a | 81 | 1520 | 760 | 128 | 759 | 82.7 MB/s 16b | 81 | 1520 | 760 | 128 | 380 | 78.6 MB/s 17a | 81 | 1536 | 768 | 128 | 767 | 89.8 MB/s 17b | 81 | 1536 | 768 | 128 | 384 | 110.3 MB/s 18a | 82 | 1552 | 776 | 128 | 775 | 101.8 MB/s 18b | 82 | 1552 | 776 | 128 | 388 | 107.5 MB/s 19a | 83 | 1568 | 784 | 128 | 783 | 114.4 MB/s 19b | 83 | 1568 | 784 | 128 | 392 | 113.9 MB/s 20a | 84 | 1584 | 792 | 128 | 791 | 113.3 MB/s 20b | 84 | 1584 | 792 | 128 | 396 | 111.2 MB/s 21a | 85 | 1600 | 800 | 128 | 799 | 114.7 MB/s 21b | 85 | 1600 | 800 | 128 | 400 | 113.8 MB/s 22a | 86 | 1616 | 808 | 128 | 807 | 112.2 MB/s 22b | 86 | 1616 | 808 | 128 | 404 | 113.5 MB/s 23a | 86 | 1632 | 816 | 128 | 815 | 96.7 MB/s 23b | 86 | 1632 | 816 | 128 | 408 | 114.5 MB/s 24a | 87 | 1648 | 824 | 128 | 823 | 114.9 MB/s 24b | 87 | 1648 | 824 | 128 | 412 | 111.4 MB/s 25a | 88 | 1664 | 832 | 128 | 831 | 114.2 MB/s 25b | 88 | 1664 | 832 | 128 | 416 | 113.5 MB/s 26a | 89 | 1680 | 840 | 128 | 839 | 113.2 MB/s 26b | 89 | 1680 | 840 | 128 | 420 | 113.8 MB/s 27a | 90 | 1696 | 848 | 128 | 847 | 112.3 MB/s 27b | 90 | 1696 | 848 | 128 | 424 | 109.8 MB/s 28a | 91 | 1712 | 856 | 128 | 855 | 113.9 MB/s 28b | 91 | 1712 | 856 | 128 | 428 | 111.6 MB/s 29a | 92 | 1728 | 864 | 128 | 863 | 114.1 MB/s 29b | 92 | 1728 | 864 | 128 | 432 | 113.5 MB/s 30a | 92 | 1744 | 872 | 128 | 871 | 113.4 MB/s 30b | 92 | 1744 | 872 | 128 | 436 | 114.0 MB/s 31a | 93 | 1760 | 880 | 128 | 879 | 112.6 MB/s 31b | 93 | 1760 | 880 | 128 | 440 | 113.3 MB/s 32a | 94 | 1776 | 888 | 128 | 887 | 114.8 MB/s 32b | 94 | 1776 | 888 | 128 | 444 | 111.6 MB/s 33a | 95 | 1792 | 896 | 128 | 895 | 114.2 MB/s 33b | 95 | 1792 | 896 | 128 | 448 | 113.9 MB/s The results below do NOT include the Basline test of current values. The Fastest Sync Speed tested was md_sync_window=824 at 114.9 MB/s Tunable (md_num_stripes): 1648 Tunable (md_sync_window): 824 Tunable (md_sync_thresh): 823 Tunable (nr_requests): 128 This will consume 87 MB with md_num_stripes=1648, 2x md_sync_window. This is 240MB less than your current utilization of 327MB. The Thriftiest Sync Speed tested was md_sync_window=640 at 111.4 MB/s Tunable (md_num_stripes): 1280 Tunable (md_sync_window): 640 Tunable (md_sync_thresh): 639 Tunable (nr_requests): 128 This will consume 68 MB with md_num_stripes=1280, 2x md_sync_window. This is 259MB less than your current utilization of 327MB. The Recommended Sync Speed is md_sync_window=656 at 114.4 MB/s Tunable (md_num_stripes): 1312 Tunable (md_sync_window): 656 Tunable (md_sync_thresh): 655 Tunable (nr_requests): 128 This will consume 69 MB with md_num_stripes=1312, 2x md_sync_window. This is 258MB less than your current utilization of 327MB. NOTE: Adding additional drives will increase memory consumption. In unRAID, go to Settings > Disk Settings to set your chosen parameter values. Completed: 9 Hrs 43 Min 28 Sec. System Info: Tower unRAID version 6.2.0-rc4 md_num_stripes=6144 md_sync_window=2768 md_sync_thresh=192 nr_requests=128 (Global Setting) sbNumDisks=13 CPU: AMD FX(tm)-8120 Eight-Core Processor RAM: 16GiB System Memory Outputting lshw information for Drives and Controllers: Bus info Device Class Description ===================================================== pci@0000:01:00.0 scsi1 storage SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] scsi@1:0.3.0 /dev/sdk disk 2TB Hitachi HUA72302 scsi@1:0.4.0 /dev/sdl disk 3TB Hitachi HUA72303 scsi@1:0.5.0 /dev/sdm disk 3TB WL3000GSA6472E scsi@1:0.6.0 /dev/sdn disk 3TB WL3000GSA6472E scsi@1:0.0.0 /dev/sdh disk 3TB WL3000GSA6472 scsi@1:0.1.0 /dev/sdi disk 1TB ST1000DM003-9YN1 scsi@1:0.2.0 /dev/sdj disk 1500GB ST1500DM003-9YN1 pci@0000:00:11.0 storage SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] pci@0000:04:00.0 scsi8 storage SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] scsi@8:0.0.0 /dev/sdo disk 3TB WL3000GSA6472E scsi@8:0.1.0 /dev/sdp disk 3TB WL3000GSA6472E scsi@8:0.2.0 /dev/sdq disk 3TB WL3000GSA6472E usb@1:5 scsi0 storage scsi@0:0.0.0 /dev/sda disk 4GB Cruzer /dev/sda disk 4GB scsi2 storage scsi@2:0.0.0 /dev/sdb disk 3200GB WL3000GSA6472E scsi3 storage scsi@3:0.0.0 /dev/sdc disk 3TB ST3000DM001-1E61 scsi4 storage scsi@4:0.0.0 /dev/sdd disk 256GB LITEONIT LCT-256 scsi5 storage scsi@5:0.0.0 /dev/sde disk 1TB TOSHIBA MQ01ABD1 scsi6 storage scsi@6:0.0.0 /dev/sdf disk 120GB KINGSTON SV300S3 scsi7 storage scsi@7:0.0.0 /dev/sdg disk 256GB SAMSUNG SSD PM83 Array Devices: Disk0 sdb is a Parity drive named parity Disk1 sdc is a Data drive named disk1 Disk2 sdi is a Data drive named disk2 Disk3 sdn is a Data drive named disk3 Disk4 sdh is a Data drive named disk4 Disk5 sdl is a Data drive named disk5 Disk6 sdk is a Data drive named disk6 Disk7 sdj is a Data drive named disk7 Disk8 sdo is a Data drive named disk8 Disk9 sdp is a Data drive named disk9 Disk10 sdq is a Data drive named disk10 Disk11 sdm is a Data drive named disk11 Outputting free low memory information... total used free shared buff/cache available Mem: 16353140 6503664 8059804 542996 1789672 8642884 Low: 16353140 8293336 8059804 High: 0 0 0 Swap: 0 0 0 *** END OF REPORT ***
-
unraid-tunables-tester.sh - A New Utility to Optimize unRAID md_* Tunables
My short test is done, Have power issues to 2 of my cages so will run it again once I replace the power connections for them unRAID Tunables Tester v4.0b by Pauven (for unRAID v6.2) Tunables Report produced Wed Aug 24 15:39:16 EDT 2016 Run on server: Tower Short Automatic Parity Sync Test NOTE: Use the smallest set of values that produce good results. Larger values increase server memory use, and may cause stability issues with unRAID, especially if you have any add-ons or plug-ins installed. Current Values: md_num_stripes=6144, md_sync_window=2768, md_sync_thresh=192 Global nr_requests=128 sdb nr_requests=128 sdc nr_requests=128 sdi nr_requests=128 sdn nr_requests=128 sdh nr_requests=128 sdl nr_requests=128 sdk nr_requests=128 sdj nr_requests=128 sdo nr_requests=128 sdp nr_requests=128 sdq nr_requests=128 sdm nr_requests=128 --- INITIAL BASELINE TEST OF CURRENT VALUES (1 Sample Point @ 30sec Duration)--- Test | RAM | num_stripes | sync_window | nr_reqs | sync_thresh | Speed ----------------------------------------------------------------------------- 1 | 327 | 6144 | 2768 | 128 | 192 | 96.0 MB/s --- FULLY AUTOMATIC nr_requests TEST 1 (4 Sample Points @ 60sec Duration)--- Test | num_stripes | sync_window | nr_requests | sync_thresh | Speed --------------------------------------------------------------------------- 1 | 1536 | 768 | 128 | 767 | 98.4 MB/s 2 | 1536 | 768 | 128 | 384 | 98.8 MB/s 3 | 1536 | 768 | 8 | 767 | 101.4 MB/s 4 | 1536 | 768 | 8 | 384 | 101.5 MB/s Fastest vals were nr_reqs=8 and sync_thresh=50% of sync_window at 101.5 MB/s This nr_requests value will be used for the next test. --- FULLY AUTOMATIC TEST PASS 1a (Rough - 13 Sample Points @ 30sec Duration)--- Test | RAM | num_stripes | sync_window | nr_reqs | sync_thresh | Speed ----------------------------------------------------------------------------- 1a | 40 | 768 | 384 | 8 | 383 | 94.1 MB/s 1b | 40 | 768 | 384 | 8 | 192 | 108.1 MB/s 2a | 47 | 896 | 448 | 8 | 447 | 108.5 MB/s 2b | 47 | 896 | 448 | 8 | 224 | 109.6 MB/s 3a | 54 | 1024 | 512 | 8 | 511 | 111.1 MB/s 3b | 54 | 1024 | 512 | 8 | 256 | 110.8 MB/s 4a | 61 | 1152 | 576 | 8 | 575 | 112.1 MB/s 4b | 61 | 1152 | 576 | 8 | 288 | 112.7 MB/s 5a | 68 | 1280 | 640 | 8 | 639 | 112.9 MB/s 5b | 68 | 1280 | 640 | 8 | 320 | 110.9 MB/s 6a | 75 | 1408 | 704 | 8 | 703 | 113.9 MB/s 6b | 75 | 1408 | 704 | 8 | 352 | 112.3 MB/s 7a | 81 | 1536 | 768 | 8 | 767 | 114.8 MB/s 7b | 81 | 1536 | 768 | 8 | 384 | 113.0 MB/s 8a | 88 | 1664 | 832 | 8 | 831 | 112.7 MB/s 8b | 88 | 1664 | 832 | 8 | 416 | 85.8 MB/s 9a | 95 | 1792 | 896 | 8 | 895 | 113.3 MB/s 9b | 95 | 1792 | 896 | 8 | 448 | 88.1 MB/s 10a | 102 | 1920 | 960 | 8 | 959 | 94.6 MB/s 10b | 102 | 1920 | 960 | 8 | 480 | 102.6 MB/s 11a | 109 | 2048 | 1024 | 8 | 1023 | 108.3 MB/s 11b | 109 | 2048 | 1024 | 8 | 512 | 112.7 MB/s 12a | 115 | 2176 | 1088 | 8 | 1087 | 108.4 MB/s 12b | 115 | 2176 | 1088 | 8 | 544 | 113.0 MB/s 13a | 122 | 2304 | 1152 | 8 | 1151 | 113.8 MB/s 13b | 122 | 2304 | 1152 | 8 | 576 | 96.8 MB/s --- FULLY AUTOMATIC TEST PASS 1c (Rough - 18 Sample Points @ 30sec Duration)--- Test | RAM | num_stripes | sync_window | nr_reqs | sync_thresh | Speed ----------------------------------------------------------------------------- 1a | 129 | 2432 | 1216 | 8 | 1215 | 115.0 MB/s 1b | 129 | 2432 | 1216 | 8 | 608 | 98.0 MB/s 2a | 136 | 2560 | 1280 | 8 | 1279 | 112.1 MB/s 2b | 136 | 2560 | 1280 | 8 | 640 | 104.3 MB/s 3a | 143 | 2688 | 1344 | 8 | 1343 | 114.9 MB/s 3b | 143 | 2688 | 1344 | 8 | 672 | 112.3 MB/s 4a | 150 | 2816 | 1408 | 8 | 1407 | 111.2 MB/s 4b | 150 | 2816 | 1408 | 8 | 704 | 115.3 MB/s 5a | 156 | 2944 | 1472 | 8 | 1471 | 114.4 MB/s 5b | 156 | 2944 | 1472 | 8 | 736 | 103.0 MB/s 6a | 163 | 3072 | 1536 | 8 | 1535 | 113.3 MB/s 6b | 163 | 3072 | 1536 | 8 | 768 | 113.7 MB/s 7a | 170 | 3200 | 1600 | 8 | 1599 | 112.3 MB/s 7b | 170 | 3200 | 1600 | 8 | 800 | 112.4 MB/s 8a | 177 | 3328 | 1664 | 8 | 1663 | 113.2 MB/s 8b | 177 | 3328 | 1664 | 8 | 832 | 111.9 MB/s 9a | 184 | 3456 | 1728 | 8 | 1727 | 112.3 MB/s 9b | 184 | 3456 | 1728 | 8 | 864 | 115.0 MB/s 10a | 191 | 3584 | 1792 | 8 | 1791 | 113.5 MB/s 10b | 191 | 3584 | 1792 | 8 | 896 | 95.1 MB/s 11a | 197 | 3712 | 1856 | 8 | 1855 | 114.3 MB/s 11b | 197 | 3712 | 1856 | 8 | 928 | 111.6 MB/s 12a | 204 | 3840 | 1920 | 8 | 1919 | 112.1 MB/s 12b | 204 | 3840 | 1920 | 8 | 960 | 113.5 MB/s 13a | 211 | 3968 | 1984 | 8 | 1983 | 113.8 MB/s 13b | 211 | 3968 | 1984 | 8 | 992 | 107.3 MB/s 14a | 218 | 4096 | 2048 | 8 | 2047 | 106.3 MB/s 14b | 218 | 4096 | 2048 | 8 | 1024 | 114.6 MB/s 15a | 225 | 4224 | 2112 | 8 | 2111 | 112.6 MB/s 15b | 225 | 4224 | 2112 | 8 | 1056 | 112.5 MB/s 16a | 231 | 4352 | 2176 | 8 | 2175 | 113.6 MB/s 16b | 231 | 4352 | 2176 | 8 | 1088 | 113.8 MB/s 17a | 238 | 4480 | 2240 | 8 | 2239 | 112.1 MB/s 17b | 238 | 4480 | 2240 | 8 | 1120 | 114.4 MB/s 18a | 245 | 4608 | 2304 | 8 | 2303 | 113.3 MB/s 18b | 245 | 4608 | 2304 | 8 | 1152 | 114.6 MB/s --- Targeting Fastest Result of md_sync_window 1408 bytes for Final Pass --- --- FULLY AUTOMATIC nr_requests TEST 2 (4 Sample Points @ 60sec Duration)--- Test | num_stripes | sync_window | nr_requests | sync_thresh | Speed --------------------------------------------------------------------------- 1 | 2816 | 1408 | 128 | 1407 | 113.8 MB/s 2 | 2816 | 1408 | 128 | 704 | 103.1 MB/s 3 | 2816 | 1408 | 8 | 1407 | 108.0 MB/s 4 | 2816 | 1408 | 8 | 704 | 112.7 MB/s Fastest vals were nr_reqs=128 and sync_thresh=99% of sync_window at 113.8 MB/s This nr_requests value will be used for the next test. --- FULLY AUTOMATIC TEST PASS 2 (Fine - 33 Sample Points @ 30sec Duration)--- Test | RAM | num_stripes | sync_window | nr_reqs | sync_thresh | Speed ----------------------------------------------------------------------------- 1a | 136 | 2560 | 1280 | 128 | 1279 | 114.8 MB/s 1b | 136 | 2560 | 1280 | 128 | 640 | 113.1 MB/s 2a | 137 | 2576 | 1288 | 128 | 1287 | 96.2 MB/s 2b | 137 | 2576 | 1288 | 128 | 644 | 112.5 MB/s 3a | 138 | 2592 | 1296 | 128 | 1295 | 113.6 MB/s 3b | 138 | 2592 | 1296 | 128 | 648 | 112.4 MB/s 4a | 139 | 2608 | 1304 | 128 | 1303 | 114.3 MB/s 4b | 139 | 2608 | 1304 | 128 | 652 | 113.2 MB/s 5a | 139 | 2624 | 1312 | 128 | 1311 | 114.6 MB/s 5b | 139 | 2624 | 1312 | 128 | 656 | 112.5 MB/s 6a | 140 | 2640 | 1320 | 128 | 1319 | 114.0 MB/s 6b | 140 | 2640 | 1320 | 128 | 660 | 113.1 MB/s 7a | 141 | 2656 | 1328 | 128 | 1327 | 113.3 MB/s 7b | 141 | 2656 | 1328 | 128 | 664 | 113.4 MB/s 8a | 142 | 2672 | 1336 | 128 | 1335 | 113.6 MB/s 8b | 142 | 2672 | 1336 | 128 | 668 | 114.5 MB/s 9a | 143 | 2688 | 1344 | 128 | 1343 | 112.8 MB/s 9b | 143 | 2688 | 1344 | 128 | 672 | 114.3 MB/s 10a | 144 | 2704 | 1352 | 128 | 1351 | 113.8 MB/s 10b | 144 | 2704 | 1352 | 128 | 676 | 114.2 MB/s 11a | 144 | 2720 | 1360 | 128 | 1359 | 114.4 MB/s 11b | 144 | 2720 | 1360 | 128 | 680 | 114.1 MB/s 12a | 145 | 2736 | 1368 | 128 | 1367 | 109.9 MB/s 12b | 145 | 2736 | 1368 | 128 | 684 | 114.9 MB/s 13a | 146 | 2752 | 1376 | 128 | 1375 | 113.6 MB/s 13b | 146 | 2752 | 1376 | 128 | 688 | 114.4 MB/s 14a | 147 | 2768 | 1384 | 128 | 1383 | 113.6 MB/s 14b | 147 | 2768 | 1384 | 128 | 692 | 113.2 MB/s 15a | 148 | 2784 | 1392 | 128 | 1391 | 113.0 MB/s 15b | 148 | 2784 | 1392 | 128 | 696 | 90.0 MB/s 16a | 149 | 2800 | 1400 | 128 | 1399 | 112.6 MB/s 16b | 149 | 2800 | 1400 | 128 | 700 | 113.0 MB/s 17a | 150 | 2816 | 1408 | 128 | 1407 | 114.4 MB/s 17b | 150 | 2816 | 1408 | 128 | 704 | 113.4 MB/s 18a | 150 | 2832 | 1416 | 128 | 1415 | 114.1 MB/s 18b | 150 | 2832 | 1416 | 128 | 708 | 112.4 MB/s 19a | 151 | 2848 | 1424 | 128 | 1423 | 114.9 MB/s 19b | 151 | 2848 | 1424 | 128 | 712 | 113.2 MB/s 20a | 152 | 2864 | 1432 | 128 | 1431 | 114.8 MB/s 20b | 152 | 2864 | 1432 | 128 | 716 | 113.0 MB/s 21a | 153 | 2880 | 1440 | 128 | 1439 | 114.9 MB/s 21b | 153 | 2880 | 1440 | 128 | 720 | 107.7 MB/s 22a | 154 | 2896 | 1448 | 128 | 1447 | 113.4 MB/s 22b | 154 | 2896 | 1448 | 128 | 724 | 112.2 MB/s 23a | 155 | 2912 | 1456 | 128 | 1455 | 114.3 MB/s 23b | 155 | 2912 | 1456 | 128 | 728 | 113.4 MB/s 24a | 156 | 2928 | 1464 | 128 | 1463 | 113.8 MB/s 24b | 156 | 2928 | 1464 | 128 | 732 | 113.5 MB/s 25a | 156 | 2944 | 1472 | 128 | 1471 | 114.8 MB/s 25b | 156 | 2944 | 1472 | 128 | 736 | 114.4 MB/s 26a | 157 | 2960 | 1480 | 128 | 1479 | 113.7 MB/s 26b | 157 | 2960 | 1480 | 128 | 740 | 114.1 MB/s 27a | 158 | 2976 | 1488 | 128 | 1487 | 114.3 MB/s 27b | 158 | 2976 | 1488 | 128 | 744 | 112.8 MB/s 28a | 159 | 2992 | 1496 | 128 | 1495 | 112.5 MB/s 28b | 159 | 2992 | 1496 | 128 | 748 | 109.9 MB/s 29a | 160 | 3008 | 1504 | 128 | 1503 | 102.4 MB/s 29b | 160 | 3008 | 1504 | 128 | 752 | 113.2 MB/s 30a | 161 | 3024 | 1512 | 128 | 1511 | 114.2 MB/s 30b | 161 | 3024 | 1512 | 128 | 756 | 100.6 MB/s 31a | 162 | 3040 | 1520 | 128 | 1519 | 113.7 MB/s 31b | 162 | 3040 | 1520 | 128 | 760 | 104.1 MB/s 32a | 162 | 3056 | 1528 | 128 | 1527 | 114.1 MB/s 32b | 162 | 3056 | 1528 | 128 | 764 | 113.2 MB/s 33a | 163 | 3072 | 1536 | 128 | 1535 | 114.1 MB/s 33b | 163 | 3072 | 1536 | 128 | 768 | 115.0 MB/s The results below do NOT include the Basline test of current values. The Fastest Sync Speed tested was md_sync_window=1216 at 115.0 MB/s Tunable (md_num_stripes): 2432 Tunable (md_sync_window): 1216 Tunable (md_sync_thresh): 1215 Tunable (nr_requests): 128 This will consume 129 MB with md_num_stripes=2432, 2x md_sync_window. This is 198MB less than your current utilization of 327MB. n The Thriftiest Sync Speed tested was md_sync_window=512 at 111.1 MB/s Tunable (md_num_stripes): 1024 Tunable (md_sync_window): 512 Tunable (md_sync_thresh): 511 Tunable (nr_requests): 128 This will consume 54 MB with md_num_stripes=1024, 2x md_sync_window. This is 273MB less than your current utilization of 327MB. NOTE: Adding additional drives will increase memory consumption. In unRAID, go to Settings > Disk Settings to set your chosen parameter values. Completed: 1 Hrs 16 Min 38 Sec. System Info: Tower unRAID version 6.2.0-rc4 md_num_stripes=6144 md_sync_window=2768 md_sync_thresh=192 nr_requests=128 (Global Setting) sbNumDisks=13 CPU: RAM: Outputting lshw information for Drives and Controllers: Bus info Device Class Description ===================================================== pci@0000:01:00.0 scsi1 storage SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] scsi@1:0.3.0 /dev/sdk disk 2TB Hitachi HUA72302 scsi@1:0.4.0 /dev/sdl disk 3TB Hitachi HUA72303 scsi@1:0.5.0 /dev/sdm disk 3TB WL3000GSA6472E scsi@1:0.6.0 /dev/sdn disk 3TB WL3000GSA6472E scsi@1:0.0.0 /dev/sdh disk 3TB WL3000GSA6472 scsi@1:0.1.0 /dev/sdi disk 1TB ST1000DM003-9YN1 scsi@1:0.2.0 /dev/sdj disk 1500GB ST1500DM003-9YN1 pci@0000:00:11.0 storage SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] pci@0000:04:00.0 scsi8 storage SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] scsi@8:0.0.0 /dev/sdo disk 3TB WL3000GSA6472E scsi@8:0.1.0 /dev/sdp disk 3TB WL3000GSA6472E scsi@8:0.2.0 /dev/sdq disk 3TB WL3000GSA6472E usb@1:5 scsi0 storage scsi@0:0.0.0 /dev/sda disk 4GB Cruzer /dev/sda disk 4GB scsi2 storage scsi@2:0.0.0 /dev/sdb disk 3200GB WL3000GSA6472E scsi3 storage scsi@3:0.0.0 /dev/sdc disk 3TB ST3000DM001-1E61 scsi4 storage scsi@4:0.0.0 /dev/sdd disk 256GB LITEONIT LCT-256 scsi5 storage scsi@5:0.0.0 /dev/sde disk 1TB TOSHIBA MQ01ABD1 scsi6 storage scsi@6:0.0.0 /dev/sdf disk 120GB KINGSTON SV300S3 scsi7 storage scsi@7:0.0.0 /dev/sdg disk 256GB SAMSUNG SSD PM83 Array Devices: Disk0 sdb is a Parity drive named parity Disk1 sdc is a Data drive named disk1 Disk2 sdi is a Data drive named disk2 Disk3 sdn is a Data drive named disk3 Disk4 sdh is a Data drive named disk4 Disk5 sdl is a Data drive named disk5 Disk6 sdk is a Data drive named disk6 Disk7 sdj is a Data drive named disk7 Disk8 sdo is a Data drive named disk8 Disk9 sdp is a Data drive named disk9 Disk10 sdq is a Data drive named disk10 Disk11 sdm is a Data drive named disk11 Outputting free low memory information... total used free shared buff/cache available Mem: 16353140 6444848 8227220 528572 1681072 8753760 Low: 16353140 8125920 8227220 High: 0 0 0 Swap: 0 0 0 *** END OF REPORT ***
-
unraid-tunables-tester.sh - A New Utility to Optimize unRAID md_* Tunables
I received the PM
-
unraid-tunables-tester.sh - A New Utility to Optimize unRAID md_* Tunables
I would love to beta test this
-
[Support] Linuxserver.io - Plex Media Server
What version of Unraid you using? I used to see this in my syslog a few releases back, I remember it being harmless and that archedraft and I both saw the same thing. I am using 6.1.9 No Windows 10 PC's in the house. No Windows machines at all actually. When I open up my syslog in the unraid gui this is pretty much the only log I see repeated to infinity....and it is definitely coming from Plex. Issue persists with v1.0 Do you share your plex server with anyone that could be using a windows machine to view content? I am not seeing this issue on my system at all
-
[Support] Linuxserver.io - Plex Media Server
I just checked there site and downloads still come from the same place.
-
[Support] Linuxserver.io - Plex Media Server
I had no problem updating to v1.0.0 all I did was restart the plex docker from my logs *** Running /etc/my_init.d/10_dbus.sh... *** Running /etc/my_init.d/20_apt_update.sh... *** Running /etc/my_init.d/30_update_plex.sh... Target version: 1.0.0.2261-xxxxxxx set by: latest\plexpass Upgrading from version: 0.9.17.3.2239-fe07491 to version: 1.0.0.2261-xxxxxxx --2016-06-24 08:55:22-- https://downloads.plex.tv/plex-media-server/1.0.0.2261-xxxxxxxxxxx/plexmediaserver_1.0.0.2261-xxxxxxxxx_amd64.deb Resolving downloads.plex.tv (downloads.plex.tv)... 104.20.7.9, 104.20.6.9, 2400:cb00:2048:1::6814:709, ... Connecting to downloads.plex.tv (downloads.plex.tv)|104.20.7.9|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 99524576 (95M) [application/octet-stream]
-
[Support] binhex - DelugeVPN
I have this issue with DelugeVPN and also had it with one of my personal dockers. I did a rebuild on docker hub for mine and it fixed the issue, so possibly if binhex forces a rebuild at docker hub might fix it.
-
[Support] binhex - DelugeVPN
Hi thanks did that and i can pull the docker image down now. I installed it last night and works fine. However i am getting the update message again this morning. I update it then when i check for updates again it says it needs updating? @naturalcarr are you getting update messages since your reinstall? Yeah I still get it when I mount my array, but that's it, so as long as my server and docker are on and enabled, it's not an issue. Sent from my SM-N910T using Tapatalk I get the same thing. It is fine till I reboot the server or click the check for updates button.
-
[Support] Linuxserver.io - Plex Media Server
Here is a quick video showing how to get the full version number
-
[Support] Linuxserver.io - Plex Media Server
I am on 6.2 B21 and Plex docker is running fine for me
-
[Support] binhex - DelugeVPN
I have VPN_REMOTE = nl.privateinternetaccess.com
-
[Support] binhex - DelugeVPN
I use PIA also. Do you have a router that could be blocking the ports?
-
[Support] binhex - DelugeVPN
First thing i would check is go into deluge ( with VPN active ) and in preferences -> network click on "Test Active Port" and make sure that is ok. Every once in a while I have to restart the docker to get it green instead of triangle warning
-
[Support] binhex - DelugeVPN
I am having no issues with seeding with VPN enabled. What VPN provider are you using?
-
[Support] binhex - DelugeVPN
ok thats interesting!, so your running standard unraid yes?, not as a vmware esxi vm or custom build to include drives and firmware for dvb? Yes, Standard unraid
-
[Support] binhex - DelugeVPN
I am on 6.1.8 and have iptable_mangle root@Tower:~# lsmod Module Size Used by xt_CHECKSUM 1071 1 ipt_REJECT 1193 2 nf_reject_ipv4 2203 1 ipt_REJECT ebtable_filter 1671 0 ebtables 14192 1 ebtable_filter kvm_amd 44207 3 kvm 251442 1 kvm_amd vhost_net 7781 1 vhost 12549 1 vhost_net macvtap 9003 1 vhost_net macvlan 11713 1 macvtap iptable_mangle 1376 1 tun 16465 8 vhost_net xt_nat 1665 16 veth 4401 0 ipt_MASQUERADE 981 16 nf_nat_masquerade_ipv4 1649 1 ipt_MASQUERADE iptable_nat 1615 1 nf_conntrack_ipv4 5626 12 nf_nat_ipv4 4111 1 iptable_nat iptable_filter 1280 2 ip_tables 9310 3 iptable_filter,iptable_mangle,iptable_nat nf_nat 9789 3 nf_nat_ipv4,xt_nat,nf_nat_masquerade_ipv4 md_mod 30680 7 it87 23702 0 hwmon_vid 2028 1 it87 fam15h_power 2406 0 k10temp 2684 0 r8169 57464 0 mii 3339 1 r8169 i2c_piix4 7688 0 ahci 24107 6 mpt2sas 148914 6 libahci 18687 1 ahci raid_class 3116 1 mpt2sas scsi_transport_sas 21182 1 mpt2sas acpi_cpufreq 6074 0