sysctl in GUI has no effect?

[datnus]

Hi everyone,
I used FreeNAS 8.3
When I set vfs.zfs.txg.timeout=1 in the syctl in GUI, why when I query in commandline
"sysctl vfs.zfs.txg.timeout", the system still replies as old value 5?

Does sysctl in GUI has any effect?

 

[William Grzybowski]

Works just fine for me, make sure you didn't typo it.

 

[datnus]

I believe this is a sysctl (not a tunable?)
1) You can see the mistmatch between the two pictures?
2) And I'm unable to set the sysctl by command line. It's readonly???

 

[cyberjock]

Perhaps. Did you reboot after enabling that?

 

[datnus]

Oops, I need to reboot after every change?
Rebooting server is not simple.

 

[cyberjock]

Actually, I'm not sure now that I look closer. I know many settings do require reboot, but I'm not sure about that exact one. I'd do a reboot before you assume it doesn't work or think you've done something wrong.

 

[cyberjock]

Ok, so "tunables" definitely require a reboot. It looks like "sysctls" may require a reboot(some do and some don't). Go figure!

It is weird that your system said it was read-only. I'd probably do a reboot just to be sure before going further with troubleshooting.

 

[datnus]

"As soon as you add or edit a sysctl, the running kernel will change that variable to the value you specify. As long as the sysctl exists, that value will persist across reboots and upgrades."
http://doc.freenas.org/index.php/Sysctls

The documentation doesn't mention about rebooting the server after adding a sysctl.

 

[cyberjock]

Answer:

"read only" sysctls can only be changed on (re)boot.

http://www5.us.freebsd.org/doc/handbook/configtuning-sysctl.html

 

[cyberjock]

I have updated the wiki and manual to include some info on read-only sysctls. :)

http://wiki.freenas.org/index.php/Sysctls

 

[datnus]

Then what if I set using zfs set zfs:write_limit_shift?

 

[cyberjock]

Not sure. I don't do tuning of the system of any kind without getting feedback from an authority on a setting change because typos or improper settings can make the system unresponsive, unbootable, cause a loss of data and/or perform incredibly poorly. The ZFS tuning guide isn't nicknamed the "ZFS Evil Tuning Guide" for nothing. It is evil, and if you aren't very experienced in it you may be sorry you even knew what a sysctl was. :P

 

[datnus]

This is to comfirm vfs.zfs.prefetch_disable could be set correctly and displayed correctly in commandline.
So for the "readonly" sysctls, we can't change them live.
FreeNas has no way to show if the sysctls in on effect.

 

[cyberjock]

Yeah, I added a comment in the sysctls wiki page(which will propagate to the FreeNAS manual) that provides an example for how to determine if a sysctl is readonly or not.

Can I presume that you've enabled the prefetch from its disabled state for systems with 4GB of RAM or less?

 

[datnus]

I only use vfs.zfs.prefetch_disable as an example on my test FreeNAS

This doesn't seem to work on FreeNAS
Linux provides a sysctl interface for checking and modifying kernel parameters which are listed under /proc/sys directory. You can persistently set or change those kernel parameters via /etc/sysctl.conf.
If you have modified /etc/sysctl.conf, and want to activate the change in the kernel without rebooting, you need to do the following.
On FreeBSD:
$ sudo /etc/rc.d/sysctl reload
http://xmodulo.com/2012/04/how-to-reload-sysctlconf.html

 

[cyberjock]

Some sysctls are only used to start or stop services. For example, if ZFS simply takes that parameter and starts the prefetch routines on bootup if vfs.zfs.prefetch_disable=0 and you change it later it won't really change the behavior of the system. The prefetch routines are already running. How that setting actually behaves on the system would be important to understanding if a reboot might be needed to actually get the intended behavior.

My guess is that the system is working as designed but since you are trying to avoid a reboot you're going to have some issues with some parameters. The typical reply for past questions with sysctls and tunables has been to reboot. That doesn't really help you right now though since you've said that rebooting isn't an option.

 

[datnus]

I have scheduled a reboot.
But if I don't "like" the parameters, I need to reboot again.

Rebooting should only happen in Windows world instead.

 

[datnus]

What I want is to set
- vfs.zfs.txg.timeout=120
- vfs.zfs.txg.synctime_ms=2000

to "convert" random IO to sequential IO.
However, I'm not quite sure about the performance.
If I don't like the settings, reboot again is painfu.

-----------
If I upgrade from 16GB RAM to 64 GB RAM and enable autotune then reboot, would autotune help me to to "convert" random IO to sequential IO
or change the above two sysctl accordingly?

 

[cyberjock]

Um, you can't convert random IO to sequential IO the way you think you can. All IOs are somewhat(kind of) converted to sequential as long as they aren't sync writes.

I will tell you that setting your timeout to 120 seconds is going to be a very very very big mistake. You are going to possibly have issues where the data written will take 10+ seconds to write every 120 seconds. In essence, your system will be really fast for 120 seconds, then be completely unresponsive while it writes all the data in RAM to the pool. For your own sake you should be hoping to have LOTS sync writes so that the system doesn't go catatonic. Of course, that defeats the purpose of what you are trying to do. And if you only have 16GB of RAM you are in even deeper doo-doo because you'll potentially empty out the ARC trying to store all this writable data which will tank your read performance. And don't get me started on what happens if the system crashes. ;)

As for the synctime_ms, it doesn't work quite the same way you think it does either. I'd normally hope one of our mods that knows tweaking better than most would step in, but he hasn't been around in almost a month.

Remember all that stuff I said about tuning not being easy and there's a reason why "evil" is often applied to tuning. I think you're about to find out just how evil tuning can be. I'm assuming you are trying to fix your latency issues from the thread http://forums.freenas.org/threads/latency-spike-for-iscsi.14612/

 

[datnus]

The problem is still there even if I reboot my server.
I.e: The readonly sysctl in the GUI and command line show different values.
Anything to do with "autotune" feature?