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.
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 pgpkeys.eu and other hockeypuck
installs is that pgpkeys.eu 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 pgpkeys.eu 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 pgpkeys.eu is getting different update sets from two different
sources and they keep overwriting each other, or some such.
Investigations continue... :-)
signature.asc