Tips and Tweaks Plugin to possibly improve performance of Unraid and VMs


Recommended Posts

Hey dlandon, I have the 2016.09.16 version of Tips and Tweaks on 6.2 final.  When I start the array I get this error on the console:

/usr/local/emhttp/plugins/tips.and.tweaks/scripts/rc.tweaks: line 69: [: =: unary operator expected.

 

Line 69 is:

if [ $POWERDOWN = "yes" ]; then

but I don't see any other instances of POWERDOWN in the script?

 

I also get the same and line 60 as well.

 

Go to the tweaks page and make a change, then save it.  That will fix the problem.

Link to comment

My last update was made in a bit of a rush and I did not handle a new configuration parameter very well that was added.  Those that updated would see the message because POWERDOWN was undefined.

 

Once you re-write the configuration file, the new parameter will get written and all will be well again.

Link to comment
  • 2 weeks later...

Saw a post in the Powerdown support thread that Tips and Tweaks could be used to save log files on reboot in the same fashion that Powerdown used to. Don't see how to enable that though. Nothing in the settings seems to pertain to log files at all.

 

It was removed because it doesn't work well with the new builtin powerdown process.  LT will be adding in diagnostics when the server is shutdown.  I expect more logging and archiving of logs could be added as they get time.

 

You could post a feature request for the log archiving.

Link to comment

I just had an interesting situation happen to me that I've not seen before.  I am running the mainline version 6.3.0-rc1 and have found that my Windows 10 VM that I use as a desktop stutters with heavy cache drive activity.  My Dockers and VM are on my SSD cache drive.  I have 32GB of memory.  I set the 'Disk Cache 'vm.dirty_background_ratio' (%):' value to 5% and the 'Disk Cache 'vm.dirty_ratio (%):' to 10%.  This is half the default values in both cases.  The stuttering stopped.  I'm wondering if Linux changed some of the disk buffering that is now causing this issue for me.

 

IMO, I think the default values may have been fine in the single digit GB memory days, but are way too high for large amounts of memory.  I think single digit values for these two settings are best.

 

Anyone else have any issues like this?

Link to comment

I installed the Tips & Tweaks plugin on a 6.3.0-rc1 unRAID VM, where "/usr/bin/cpufreq-info -d" doesn't return anything.

 

The plugin throws this error on the console:

 

/usr/local/emhttp/plugins/tips.and.tweaks/scripts/rc.tweaks#: line 188: [: !=: unary operator expected

 

Adding quotes around $value on line 188 seems to take care of it:

 if [ "$value" != "" ]; then

Link to comment

I installed the Tips & Tweaks plugin on a 6.3.0-rc1 unRAID VM, where "/usr/bin/cpufreq-info -d" doesn't return anything.

 

The plugin throws this error on the console:

 

/usr/local/emhttp/plugins/tips.and.tweaks/scripts/rc.tweaks#: line 188: [: !=: unary operator expected

 

Adding quotes around $value on line 188 seems to take care of it:

 if [ "$value" != "" ]; then

 

Sorry, at bootup line 53 throws a similar error for a similar reason:

 

/usr/local/emhttp/plugins/tips.and.tweaks/scripts/rc.tweaks#: line 53: [: ==: unary operator expected

Link to comment

I installed the Tips & Tweaks plugin on a 6.3.0-rc1 unRAID VM, where "/usr/bin/cpufreq-info -d" doesn't return anything.

 

The plugin throws this error on the console:

 

/usr/local/emhttp/plugins/tips.and.tweaks/scripts/rc.tweaks#: line 188: [: !=: unary operator expected

 

Adding quotes around $value on line 188 seems to take care of it:

 if [ "$value" != "" ]; then

 

Sorry, at bootup line 53 throws a similar error for a similar reason:

 

/usr/local/emhttp/plugins/tips.and.tweaks/scripts/rc.tweaks#: line 53: [: ==: unary operator expected

 

Thanks!  The VM boots without errors on the console now :)

Link to comment
  • 1 month later...

Hi,

 

First off, thank you for this useful plugin!

 

Some of us are having issues with the turbo function being turned off with the Intel Pstate driver. it is turned back on by running the following:

echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo

 

The issue is that this is not persistent between reboots. I was looking into how to get it to be permanent when it occurred to me that this plugin might be the best place for that setting, since you are already setting the scaling of the governor. Users might find it useful to turn turbo on and off in the same place as they are setting the governor mode.

 

Thoughts?

Link to comment

Hi,

 

First off, thank you for this useful plugin!

 

Some of us are having issues with the turbo function being turned off with the Intel Pstate driver. it is turned back on by running the following:

echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo

 

The issue is that this is not persistent between reboots. I was looking into how to get it to be permanent when it occurred to me that this plugin might be the best place for that setting, since you are already setting the scaling of the governor. Users might find it useful to turn turbo on and off in the same place as they are setting the governor mode.

 

Thoughts?

 

The turbo mode is intentionally turned off by Tips and Tweaks because I found when turned on, it ran the processor at turbo speed all the time.

 

I could add an option to turn turbo mode on/off as desired when the Intel Pstate driver is used.

Link to comment

Thanks for the quick turnaround dlandon, much appreciated. I saw this option come through on the latest update.

 

Admittedly the behavior of this option is odd. The unRAID server itself scales the CPU correctly but my Ubuntu VM says it's pegged at 3.3Ghz. The CPU is clocked at 4.4 so I'm guessing the VM just assumes the clock is at default. However, the core speed on the host definitely drops below 3.3Ghz on the cores being used by the VM so it is not actually pegging the CPU.

 

unRAID host

cpu MHz		: 3156.793
cpu MHz		: 4399.932
cpu MHz		: 1236.492
cpu MHz		: 1200.036
cpu MHz		: 1246.966
cpu MHz		: 1200.842
cpu MHz		: 4185.626
cpu MHz		: 1566.009
cpu MHz		: 1370.635
cpu MHz		: 4195.898
cpu MHz		: 3823.278
cpu MHz		: 1340.826

 

Guest VM

cpu MHz		: 3299.964
cpu MHz		: 3299.964
cpu MHz		: 3299.964
cpu MHz		: 3299.964
cpu MHz		: 3299.964
cpu MHz		: 3299.964
cpu MHz		: 3299.964
cpu MHz		: 3299.964

Link to comment
  • 3 months later...
  • 1 month later...

I've been seeing a couple of threads like this recently

 

 

With increasing CPU speeds, RAM, and installed containers, the default settings might not be sufficient in certain cases.

 

Wondering if it wouldn't be a bad idea to add in to tips & tweaks an option to increase the max # of open files (ulimit -n xxxxxx)

 

  • Upvote 1
Link to comment
3 hours ago, Squid said:

I've been seeing a couple of threads like this recently

 

 

With increasing CPU speeds, RAM, and installed containers, the default settings might not be sufficient in certain cases.

 

Wondering if it wouldn't be a bad idea to add in to tips & tweaks an option to increase the max # of open files (ulimit -n xxxxxx)

 

Agreed.  I'll look into it.

Link to comment
On 4/16/2017 at 6:09 PM, dlandon said:

Agreed.  I'll look into it.

I've done some work on this, but I am not sure I have the right answer.  The ulimit setting is a per user file open limit.  I don't think that will accomplish what we need.  I'm working with fs.file.max that is the system max limit that I think might be the right parameter.

 

sysctl fs.file-max

Link to comment
3 minutes ago, dlandon said:

I've done some work on this, but I am not sure I have the right answer.  The ulimit setting is a per user file open limit.  I don't think that will accomplish what we need.  I'm working with fs.file.max that is the system max limit that I think might be the right parameter.

 

sysctl fs.file-max

Personally then I wouldn't bother.  My system has 2.4M total available file handles, with 4096 currently allocated (cat /proc/sys/fs/file-nr).  Which seems way more than necessary.  Maybe the user's problem I was trying to solve was simply they were out of inodes available....

Link to comment
  • 3 months later...

I installed a while ago but just really looked through this. I saw the "Disable FTP & Telnet" option and turned that on. As I clicked "Apply" I realized, hey, I do need Telnet, that's how I remote in to the console, and sure enough PuTTY wouldn't connect. I turned off "Disable", and it still won't connect.

 

Now, as I've read through this thread, I've realized that I should be using SSH. I've reconfigured my saved PuTTY session to use SSH and it works fine. For my server's security, I'll be leaving this setting enabled.

 

However, I'm reporting this because setting "Disable FTP Server & Telnet" back to "No" doesn't seem to reenable telnet (haven't tested FTP). While I get that it should really remain that way for security, most users would expect that setting it back to "No" would reestablish telnet services.

 

Link to comment
26 minutes ago, FreeMan said:

However, I'm reporting this because setting "Disable FTP Server & Telnet" back to "No" doesn't seem to reenable telnet (haven't tested FTP). While I get that it should really remain that way for security, most users would expect that setting it back to "No" would reestablish telnet services.

 

In the back of my mind, I seem to recall that a reboot is necessary to re-enable telnet after it has been disabled.  I was going to suggest modifying the Help system to reflect that but when I checked, I found out that that suggestion has already been incorporated! 

Link to comment
12 minutes ago, Frank1940 said:

 

In the back of my mind, I seem to recall that a reboot is necessary to re-enable telnet after it has been disabled.  I was going to suggest modifying the Help system to reflect that but when I checked, I found out that that suggestion has already been incorporated! 

 

And... that's what I get for not reading.  :(  (Did I mention that I hadn't had my first cup of coffee yet and, therefore, really shouldn't have been messing about with server settings to begin with?)

 

Also, thanks, @dlandon for another great tool to supplement unRAID!

 

As you were.

  • Upvote 1
Link to comment

Getting tired of the constant "Unmounting Disks" message when you are trying to stop the array and forgot you had a bash or ssh session open?  Tips and Tweaks now has a new feature where you can specify the processes that will be killed when the array is stopped.  For example if you specify bash and ssh, any bash and ssh sessions will be killed when the array is stopped so the array disks can be unmounted.  Of course there is a risk in doing this because you may lose data when the session is closed, so be careful when using this feature.

Link to comment
33 minutes ago, dlandon said:

Getting tired of the constant "Unmounting Disks" message when you are trying to stop the array and forgot you had a bash or ssh session open?  Tips and Tweaks now has a new feature where you can specify the processes that will be killed when the array is stopped.  For example if you specify bash and ssh, any bash and ssh sessions will be killed when the array is stopped so the array disks can be unmounted.  Of course there is a risk in doing this because you may lose data when the session is closed, so be careful when using this feature.

 

A suggestion on wording of this new feature.  Rather then calling it "Processes to kill when Array is Stopped:", I would calling it:  "Processes to kill when Array is Being Stopped:" (I interpreted the purpose of this new addition from its name was to kill processes after the array was actually stopped.  But after looking at the new function and the 'Help' on it and knowing a bit of background about the reason that it had been requested, I believe it actually either (1) runs before the Stop Array starts or (2) a predetermine time after the Stop Array has started.) 

Edited by Frank1940
Link to comment
2 hours ago, Frank1940 said:

 

A suggestion on wording of this new feature.  Rather then calling it "Processes to kill when Array is Stopped:", I would calling it:  "Processes to kill when Array is Being Stopped:" (I interpreted the purpose of this new addition from its name was to kill processes after the array was actually stopped.  But after looking at the new function and the 'Help' on it and knowing a bit of background about the reason that it had been requested, I believe it actually either (1) runs before the Stop Array starts or (2) a predetermine time after the Stop Array has started.) 

I changed the wording and help description.  The processes are actually killed at an event before the unmounting of the disks.

  • Like 1
Link to comment
23 minutes ago, dlandon said:

I changed the wording and help description.  The processes are actually killed at an event before the unmounting of the disks.

 

I think your wording is better than mine and it very big improvement on the original which will clarify exactly what will happen to any process that is listed to anyone who has not seen the postings about the problem which prompted the inclusion of this functionality. 

Link to comment
  • 4 weeks later...

Request. Not sure if this is the venue to do it, but since a lot of us use SSH over Telent could there be a disable Root login added for SSH via this plugin? I purposely use a user to login and then switch to su to do what I need to do to deny direct root logins.  I did it using a Plugin long time ago called ssh Plugin a while back from docgyver 2016.02.25.2 to accomplish this and I no longer see it as downloadable/install able since SSH comes installed. 

 

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.