[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: High rate of updated keys

From: Marcel Waldvogel
Subject: Re: High rate of updated keys
Date: Wed, 12 May 2021 10:56:35 +0200
User-agent: Evolution 3.40.0-1

I have not investigated closely, but I noticed that after a restart of the Hockeypuck server, several hundred "updates" are being processed (I am using the version which does negative caching of recon attempts which did not result in updates).

So, maybe we need to look closer at what actually counts as an "update" for Hockeypuck.

An alternate explanation would be that the changes being applied are not idempotent or cumulative, e.g., that some UIDs or signatures are being reordered, which is counten as an update. And, in theory, several of those changes might be circulating in the network, updating each other again and again (even though I guess that over time, some of the updates should "win" over the others). 

But as I said, I'm just guessing wildly right now.


Am Dienstag, dem 11.05.2021 um 15:10 +0100 schrieb Andrew Gallagher:
On 08/05/2021 20:23, Andreas Puls wrote:
Im running on both of my servers the deafult value.

I think the main difference between and other hockeypuck
installs is that recons directly with three of the biggest
SKS pool members, while most other hockeypuck installs do not. I
temporarily disabled recon with all SKS peers and the number of modified
keys immediately fell back to normal levels.

I suspect this may be related to the hockeypuck/SKS recon thrashing
problem that Marcel diagnosed - the number of updated keys does not seem
to reflect actual updates but rather update attempts, and as the SKS and
Hockeypuck datasets have diverged, so have the number of repeated sync
failures. This would appear to have been growing slowly for some time.

I'm still not sure why has been disproportionately affected -
other hockeypuck nodes have several SKS peers and haven't suffered to
the same extent. I suspect it may be an artifact of the topology -
perhaps is getting different update sets from two different
sources and they keep overwriting each other, or some such.

Investigations continue... :-)

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]