Re: High rate of NFS cache misses after upgrading from 10.3-prerelease to 11.1-release

[Rick Macklem]

Niels Kobschätzki wrote:
>On 04/14/2018 03:49 AM, Rick Macklem wrote:
>> Niels Kobschätzki wrote:
>>> sorry for the cross-posting but so far I had no real luck on the forum
>>> or on question, thus I want to try my luck here as well.
>> I read email lists but don't do the other stuff, so I just saw this 
>> yesterday.
>> Short answer, I haven't a clue why cache hits rate would have changed.
>>
>> The code that decides if there is a hit/miss for the attribute cache is in
>> ncl_getattrcache() and the code hasn't changed between 10.3->11.1,
>> except the old code did a mtx_lock(), but I can't imagine how that
>> would affect the code.
>>
>> You might want to:
>> # sysctl -a | fgrep vfs.nfs
>> for both the 10.3 and 11.1 systems, to check if any defaults have somehow
>> been changed. (I don't recall any being changed, but??)
>
>I did that and there did nothing change.
>
>> If you go into ncl_getattrcache() {it's in sys/fs/nfsclient/nfs_clsubs.c}
>> and add a printf() for "time_second" and "np->n_mtime.tv_sec" near the
>> top, where it calculates "timeo" from it.
>> Running this hacked kernel might show you if either of these fields is bogus.
>> (You could then printf() "timeo" and "np->n_attrtimeo" just before the "if"
>> clause that increments "attrcache_misses", which is where the cache misses
>> happen to see why it is missing the cache.)
>> If you could do this for the 10.3 kernel as well, this might indicate why the
>> miss rate has increased?
>
>I will do this next week. On monday we switch for other reasons to other
>nfs-servers and when we see that they run stable, I will do this next.
With a miss rate of 2.7%, I doubt printing the above will help. I thought
you were seeing a high miss rate.

>Btw. I calculated now the percentages. The old servers had a attr miss
>rate of something like 0.004%, while the upgraded one has more like
>2.7%. This is till low from what I've read (I remember that you should
>start adjusting acreg* when you hit more than 40% misses) but far higher
>than before.
You could try increasing acregmin, acregmax and see if the misses are reduced.
(The only risk with increasing the cache timeout is that, if another client 
changes
 the attributes, then the client will use stale ones for longer. Usually, this 
doesn't
 cause serious problems.)
To be honest, a Getattr RPC is pretty low overhead, so I doubt the increase
to 2.7% will affect your application's performance, but it is interesting that
it increased.

You might also try increasing acdirmin, acdirmax in case it is the directory
attributes that are having cache misses.

Oh, and check that your time of day clocks are in sync with the server,
since the caches are time based, since there is no cache coherency protocol
in NFS.
[good stuff snipped]
rick
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 227502] Unable to add pfsense as monitored target in ntopng

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227502

Eugene Grosbein  changed:

   What|Removed |Added

 Status|New |Open
   Assignee|ports-b...@freebsd.org  |ha...@freebsd.org
 CC||eu...@freebsd.org,
   ||n...@freebsd.org

--- Comment #1 from Eugene Grosbein  ---
I've reproduced the problem building and running third-party/snmp/test.c from
net/ntopng source tree. I run bsnmpd in debug mode:

/usr/sbin/bsnmpd -p /var/run/snmpd.pid -d -D dump,trace=0x3000

Incoming SNMPv1 GetRequest as captured and decoded by tcpdump:

04:15:32.993260 IP (tos 0x0, ttl 62, id 21558, offset 0, flags [none], proto
UDP (17), length 81)
X.X.X.X.46351 > X.X.X.X.Y: [udp sum ok]  { SNMPv1 C="xxx" {
GetRequest(34) R=1  .1.3.6.1.2.1.1.5.0 } }

bsnmpd fails to parse it producing errors:

snmpd[45132]: ASN.1: non-minimal integer at 00 00 00 00 04 07 72 65 77 6f 72 74
68 a0 22 02 04 00 00 00 01 02 04 00 00 00 00 02 04 00 00 00 00 30 0e 30 0c 06
08 2b 06 01 02 01 01 05 00 05 00
snmpd[45132]: SNMP: cannot decode version

ntopng uses bundled copy of library https://github.com/ejrh/snmp to encode SNMP
data into packets and this library seems to produce incorrect DER/ASN.1 packets
always encoding integers with 4 bytes per value. The library itself is pretty
old, it was not updated for 6 years.

snmpwalk, on the other hand, produces correct requests and bsnmpd answers just
fine.

It seems, net-snmpd tolerates such standard violation but bsnmpd does not.
Please note that other modern software tend to stick to strict validation too. 
For example, golang's library encoding/asn1 rejects such invalid "non-minimal
integer encodings" since version 1.7: https://golang.org/doc/go1.7

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 222065] security/ipsec-tools: racoon initiates phase 1 to wrong port

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222065

Eugene Grosbein  changed:

   What|Removed |Added

 CC||a...@freebsd.org,
   ||eu...@freebsd.org,
   ||n...@freebsd.org
 Status|New |Open

--- Comment #1 from Eugene Grosbein  ---
Let's see maybe ae@ has something to say on this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 225066] CVE-2016-10396 security/ipsec-tools

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225066

Eugene Grosbein  changed:

   What|Removed |Added

   Assignee|va...@freebsd.org   |eu...@freebsd.org
 CC||eu...@freebsd.org,
   ||n...@freebsd.org
 Status|New |Closed
 Resolution|--- |FIXED

--- Comment #3 from Eugene Grosbein  ---
Fixed, thank you for the report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

n32WmBq3WkZm

[Jhlt]

218.76.191.145

hlsxf.docx
Description: Binary data
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"