Tips and Tweaks

From unRAID
Jump to: navigation, search

This page is designed to collect the various tips, tricks, and tweaks that can help unRAID users perform better, safer, and possibly faster

  • There is a companion plugin for this wiki page, the Tips and Tweaks plugin, that can assist you in setting some of the tips and tweaks. The tips below are marked for it, if the plugin can be used. It is designed to make it easy to try certain tips and tweaks of this page, interactively. As the plugin says, "Make one change at a time and verify".
  • You should not blindly add every tip, they may not help you.
  • Tips that work for someone else may not work for you, or perhaps not in the same combinations of tips. Try multiple combinations (e.g. this tip off and that tip on, and vice verse, etc).
  • Unless otherwise warned, they should be safe to try out, and revert if necessary.
  • Important! You can help us by letting us know what worked and what didn't. Add your feedback either in the thread where you were directed here, or in the feedback thread for this wiki page -> Tips and Tweaks feedback
  • This page is volatile, dynamic, will probably change occasionally as new information comes to light. Some tips will be discarded as no longer needed, some will be modified as we learn more about a problem, some will be improved over time.
work in progress, tips need to be verified!


Tips for Stability

This section is specifically for tips that may help users of current versions run better, especially if they are having problems

Run the 'Fix Common Problems' plugin

Problem: You aren't positive everything is set up right, or you're having unexpected problems
Suggested fix: Install and run the Fix Common Problems plugin
Tip status: well proven, many users reporting fixes worked, improvements made
You may be surprised by the things it finds. It includes suggestions for each about what to do.

Increase num_stripes tunable

Problem: You are running 6.2-beta18 through 6.2-beta21, and server appears to hang during large file transfers (generally affects users running VM's, unsure about others)
Suggested fix: Upgrade to 6.2-beta22 or higher; or: with the array stopped, in Settings --> Disk Settings, change the tunable for num_stripes to 8192, save and restart the array
Tip status: Problem appears to be fixed in 6.2-beta22; experimental, helped a few users, didn't help others, limited testing yet
Numerous posts in 6.2 beta threads about these hangs; fix proposed by Eric here

Fix SMART database update

Problem: In 6.1.9, WebGui hangs after awhile
Suggested fix: Either fix the command, or disable the command; or upgrade to 6.2
This is for 6.1.9 (possibly for earlier versions too), fixed in 6.2 betas
Tip status: if needed, fixes the problem
For more information, see the Defect Report and the thread about webGui hanging

Disable network offloading

Problem: After awhile, networking slows way down
Suggested fix: use the Tips and Tweaks plugin, or add the lines below near the top of the config/go file
ethtool -K eth0 tso off
ethtool -K eth0 gso off
Needs field testing, but *may* keep networking speeds consistent
Tip status: Experimental, may have helped a few users, didn't help others, limited testing yet
See this

Disable network flow control

Problem: issues with network flow, throughput, and dropped packets; can possibly cause choppy video and audio in media streaming and gaming applications
Suggested fix: use the Tips and Tweaks plugin, or add the line below near the top of the config/go file
ethtool -A ethX autoneg off rx off tx off
Tip status: Experimental, may have helped a few users, didn't help others, limited testing yet
Needs field testing, but may help. When using the Tips and Tweaks plugin to change this, you may also want to adjust the transmit and receive ring buffers up or down, may also help
See this

Use static IPs

Problem: Possible issues with networking (bridging, Dockers), possibly excessive syslog entries
Suggested fix: Set networking to use a static IP, not use DHCP
Tip status: if errors on first renewal, fixes it; otherwise controversial - considered helpful by some, unnecessary by others; there are numerous networking changes in 6.2-beta22, so problem may be fixed
When you are first starting out, DHCP is great. It provides and configures for you a correct and usable IP, netmask, gateway, and DNS servers. But it comes with baggage that can cause problems. DHCP gives you a temporary lease on those settings, then requires them to be renewed every so often. That renewal can briefly unhook the current network configuration, before rehooking it all back up. In current unRAID releases, at times it doesn't appear to rehook all of the Docker connections and/or bridging correctly.
DHCP can add considerable syslog entries, especially if the DHCP server has a short lease period!
Recommendation for new users - use DHCP at first, and make a note of the settings it gives you (IP, netmask, gateway, and DNS servers). Then change to static IP and put those settings in. Don't change anything but perhaps the last byte of the IP. Make sure it's something from 2 to 254. (Unless you know what you are doing!)

Avoid jumbo frames

Problem: You are using jumbo frames, and you are having problems updating Docker containers or installing new containers
Suggested fix: For now, remove all jumbo frame options and settings, return to the MTU defaults
Tip status: Experimental, limited testing; there are numerous networking changes in 6.2-beta22, some specifically for jumbo frames so problem may be fixed - needs confirmation
Jumbo frames are nice, can help squeeze a little more bandwidth out of your network equipment. Unfortunately, certain Docker operations can be negatively affected.
For a thread with issues solved by dropping jumbo frame usage, see this
Note: while some users are having issues, that dropping jumbo frame usage solves, that doesn't mean that all jumbo frame users are having issues with them. At this time, we don't know the extent of the problem, and are hoping for feedback here that will help everyone better understand what the real issue is, what equipment is involved (all or a subset), and how many users are affected

Add CPU scaling for AMD systems

Problem: You have AMD CPU's and on the Dashboard, your CPU speeds never drop below their maximum. That means you are always using higher power, even when not needed (increasing your electric bill).
Suggested fix: Add the line below to the config/go file; you can also run it right now at a command prompt
modprobe powernow_k8
Tip status: It's not known how many AMD users are affected. The tip does work, and should be harmless for all.
As soon as the command is run, it causes CPU speed scaling/stepping on AMD based systems. You should see immediate results on Dashboard, and a lower electric bill!
Note: this is a temporary step until LimeTech fixes it. Once fixed, you should remove this from your go file.

Controlling disk caching

See Tips and Tweaks plugin

Optimizing the CPU scaling governor

See Tips and Tweaks plugin

Controlling memory overcommit

See http://lime-technology.com/forum/index.php?topic=48408.msg474031#msg474031

Freeing log space

Problem: Your system is stuck, unable to log anything, because the logging folder (/var/log) is full. You may also be able to see errors related to logging failures.
Suggested fix: Since log files over 2MB (especially over 10MB) are just junk, truncating them very quickly opens a large amount of log space, thereby freeing up those programs that are stuck, trying and failing to report issues. In a console (or Telnet, PuTTY, SSH, etc)), go to the log folder (cd /var/log), list the folder contents (ls -al), and truncate any files over 10MB with the following command -
truncate -s 2M the_file_name (upper and lower case are important)
This should immediately free log space and allow programs to function, so that you can request the Diagnostics, and cleanly shut down
Tip status: there are a few that feel this could be risky, losing good log data. I DON'T!!! There's nothing useful beyond 2MB of a file full of error messages. We only want to see the very first errors. After that, it's garbage, space clogging garbage. The truncate process has been tested, no issues.
See http://lime-technology.com/forum/index.php?topic=48265.msg463010#msg463010


Tips for Safety

This section is specifically for tips that may help users operate more safely

Backup! Backup! Backup!

Anything of value should be backed up!
Anything that's important should be backed up multiply, and one copy should be offsite

Malware protection

No disk or User share that is visible on your network should be writable, unless absolutely necessary. Make them read-only if at all possible. If write access is needed, limit how much time it is available for writing.
See Ransomware resistance
One of the most important factors in security from malware, especially ransomware, is good backups! Make sure you have a good backup strategy for anything of value, and make sure the backup location is as inaccessible to other machines as you can make it!

Stay updated!

Most unRAID releases include security fixes. If you are running an older version, you are vulnerable to attack.
This is true even if you aren't exposed to the Internet, because most attacks now-a-days probably come from other machines on our own networks.
*You* may be a safe user, but how about your relatives? If their machine is infected, it may be with something advanced enough to know how to attack other machines on the local network, including Linux machines.

Disable Telnet access

Telnet access is a security vulnerability, even if you have a well designed root password, which many don't! It's far better to use SSH. And PuTTY supports SSH, making it easy. We recommend turning off the built-in Telnet service.
To disable the built-in Telnet service, use the Tips and Tweaks plugin (easy!), or add the following 2 lines to the /boot/config/go script (these instructions are from this thread)
sed -i -e 's/^telnet/#telnet/' /etc/inetd.conf
/etc/rc.d/rc.inetd restart
This will apply when you next reboot. You can make it happen for the current session by running the 2 lines now, at a command prompt.

Disable FTP access

The built-in FTP access is a security vulnerability, even if you have well designed passwords, which many don't! If you need FTP, it's better and safer to use a ProFTP Docker or plugin, or some other FTP tool. We recommend turning off the built-in FTP service.
To disable the built-in FTP service, use the Tips and Tweaks plugin (easy!), or add the following 2 lines to the /boot/config/go script (these instructions are from this thread)
sed -i -e 's/^ftp/#ftp/' /etc/inetd.conf
/etc/rc.d/rc.inetd restart
To disable both FTP and Telnet at the same time, use the Tips and Tweaks plugin (easy!), or add the following 2 lines instead to the /boot/config/go script
sed -i -e 's/^telnet/#telnet/;s/^ftp/#ftp/' /etc/inetd.conf
/etc/rc.d/rc.inetd restart
This will apply when you next reboot. You can make it happen for the current session by running the 2 lines now, at a command prompt.


work in progress


Tips for Performance

This section is specifically for tips that may help users of current versions run faster, but hopefully just as safely

Turn on Reconstruct Write

(Highly recommended! Often called 'Turbo Write' )
Problem: Writing to parity protected data drives has always been slow, because it requires reading the old data and parity blocks, calculating the new parity, wait for platter rotation to bring the block location back around, then finally writing the data and parity blocks. This is known as 'read-modify-write' (RMW for short). A new mode has been added to unRAID called 'reconstruct write', where the data is immediately written, all of the other data disks are read, and parity is calculated then written. There is no wait for platter rotation! And no double I/O to each drive (first the read then the write). Rather than modifying parity as before, it's building it fresh.
Discussion: There's an upside and a downside to this change. The upside is it provides a huge performance boost to writes directly to array drives! Users often see speeds between 2 and 3 times as fast! (That's why it's sometimes referred to as 'Turbo Write'!) The downside is that ALL of the array drives must be spun up for EVERY write! So it's a trade-off between write speed and drives staying spun down.
Suggested fix: go to Settings then Disk Settings, and change Tunable (md_write_method) to reconstruct write
Note: the tunable option Auto currently just sets reconstruct write to off
Tip status: highly recommended! it's a fairly new feature, but so far, no reports of problems
work in progress