Replies: 2 comments
|
Not normal, and thanks for the numbers, they made this findable. The HTTP polling side caches DNS properly, but a discovery policy check that used to run once at connection setup got moved into the per node poll loop in v6.0.0, and it calls the resolver directly, bypassing Pulse's own DNS cache. With 4 nodes on the default 10 second poll that's a resolution every 2.5 seconds before the A plus AAAA doubling and any search domain fan out from your resolv.conf, which lands right around the rate you're seeing. SSH temperature collection can stack more on top since every ssh and ssh-keyscan it runs does its own fresh lookup. Quickest fix on your side is giving each cluster endpoint an IP, then the check short circuits before any lookup and this path drops to zero. An /etc/hosts entry for the nodes on the Pulse host or a local caching resolver works too. One thing that won't help is the DNS cache timeout setting, this code path never touches that cache. I'll fix it properly so the lookup goes through the cache and the policy check moves back out of the hot loop. |
|
This is fixed on main in 108aa4e. The default setup no longer touches DNS at all for that policy check, and custom allowlist or blocklist configs now cache their verdict for five minutes instead of resolving every cycle. I also added backoff to ssh-keyscan and the temperature SSH probes so a failing host doesn't get retried every 10 seconds. It'll be in the next release, and once you're on it Pulse should mostly disappear from that resolver graph. |
Uh oh!
There was an error while loading. Please reload this page.
Not sure if its normal or not, but, since switching to the v6 releases, Pulse makes up about 85% of my DNS lookup traffic on a fairly busy home network. Mostly seems to be constantly looking up the same (and only) 4 PVE nodes; doing over 500k lookups in 24hours
All reactions