'zpool iostat' in 'zfs.pm' show almost no changes in read/write Operation/Bandwidth graphs

[mikaku]

The @abqcheeks user opened a recent chat on freenode saying that the read/write values in the Operation/Bandwidth graphs in zfs.pm rarely if ever change. He explained that this is because the output from ztool iostat is the average operations per second since the system booted. This happens either in *BSD and Linux systems.

# zpool iostat -Hp <mypool>
<mypool>    12232325972992  7696322280448   10  33  62047   3844624

He proposed to append the interval and count arguments to the command line ztool iostat -Hp <mypool>, to get the average for a 5-second sample and gather the values from the second line.

[mikaku]

Although the 5-second sample won't reflect the real activity of ZFS during the last minute, it will indeed bring more information than the current configuration.

So, until we don't know a better way for doing that, this will be the default way to go.

[mikaku]

@abqcheeks, please download the latest zfs.pm and let me know if it works for you.

[mikaku]

This is a screen shot of how these values are represented after applying the patch:

[abqcheeks]

Hi ... sorry I went mia last spring regarding this project.

I finally got some time to finish the zfs freebsd stuff. I submitted a pull request against the current version which includes ARC stats.

I've got some more FreeBSD patches to submit for other modules soon.

Thanks,

Mark

On Wed, May 15, 2019 at 01:53:22AM -0700, Jordi Sanfeliu wrote:

[1]@abqcheeks, please download the latest zfs.pm and let me know if it works for you.

-- You are receiving this because you were mentioned. Reply to this email directly, [2]view it on GitHub, or [3]mute the thread.

References

1. https://github.com/abqcheeks
2. https://github.com/mikaku/Monitorix/issues/242?email_source=notifications&email_token=AA3QA6Q5R6MG2LDDROLZTILPVPFQFA5CNFSM4HNBAJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVN7USY#issuecomment-492567115
3. https://github.com/notifications/unsubscribe-auth/AA3QA6QC7W6QBV27AHAQDGTPVPFQFANCNFSM4HNBAJ3Q

-- Mark Costlow | Southwest Cyberport | Fax: +1-505-232-7975 cheeks@swcp.com | Web: www.swcp.com | Voice: +1-505-232-7992

[mikaku]

I finally got some time to finish the zfs freebsd stuff. I submitted a pull request against the current version which includes ARC stats.

Yep, just merged it.

I've got some more FreeBSD patches to submit for other modules soon.

Fantastic!

Thanks.

[abqcheeks]

 I've got some more FreeBSD patches to submit for other modules soon.

Fantastic!

Hi,

When I went back to this I realized many of the things I "fixed" were actually just updates to my config file. I did run into one issue in serv.pm where I had commented out some of the log files for things I was not using (e.g. SpamAssassin). The log file would get regular errors logged from: if(-r $config->{spamassassin_log}) {

I started to just uncomment the setting in the config file, pointing to a nonexistent file. That would shut up the errors but I figured why bother with that filesystem op when we know it's not there, so I changed it to: if(defined $config->{spamassassin_log} && -r $config->{spamassassin_log}) {

If you're OK with that, I'll submit those changes. If you don't want to, let me know.

On another topic: the nfss.pm work I did before to get nfs server stats on FreeBSD is parsing the output of "nfsstat -s" because that's the only place I could find those stats reported. I did that on FreeBSD 10 or 11. Unfortuantely nfsstat output changed in FreeBSD 12 and broke the lame parser I wrote. The changes are minor but structural so will require a separate parsing loop. But then I found they have added "libxo" support to the nfsstat command, which is an output library which will, among other things, let us get the output in JSON format.

So, that's great, I can redo this using the JSON output and be done forever instead of chasing whimsical formatting changes in that command. However, I didn't find any JSON libraries currently being imported by Monitorix. So I wanted to get your input before I add a dependency to the package.

If left to my own devices I would "use JSON::PP". Questions for you:

1. Use JSON::PP or something else?
2. Ok to have that "use" command in nfss.pm? Or do you want it protected with a config check for BSD so it doesn't force the dependency on linux users?

Thanks,

Mark -- Mark Costlow | Southwest Cyberport | Fax: +1-505-232-7975 cheeks@swcp.com | Web: www.swcp.com | Voice: +1-505-232-7992

[mikaku]

I started to just uncomment the setting in the config file, pointing to a nonexistent file. That would shut up the errors but I figured why bother with that filesystem op when we know it's not there, so I changed it to:

   if(defined $config->{spamassassin_log} && -r $config->{spamassassin_log}) {

If you're OK with that, I'll submit those changes. If you don't want to, let me know.

It looks good to me, go ahead.

If left to my own devices I would "use JSON::PP". Questions for you:

1. Use JSON::PP or something else?
2. Ok to have that "use" command in nfss.pm? Or do you want it protected with a config check for BSD so it doesn't force the dependency on linux users?

Thanks for taking care to not affect other systems when including that new Perl module.

I think that if you place the use JSON::PP line inside the FreeBSD, NetBSD and OpenBSD block of code instead of in the beginning of the file, then the Linux users won't be affected, or I'm wrong?

Thanks.