Re: [Sks-devel] Memory Leak in recon server?

[Teun Nijssen]

Hi,

on 2010-02-02 01:19 Arnold wrote the following:
> Hi,
> 
> On 02-02-10 00:15, Phil Pennock wrote:
>> On 2010-02-01 at 16:25 -0500, Daniel Kahn Gillmor wrote:
>>> Are you suggesting that if a single peer was to, say, flush its DB and
>>> re-connect, it could trigger this memory consumption on all/any of its
>>> peers?  Would the memory consumption increase proportionally to the
>>> number of peers which did this?
> 
>> What I know is that I personally have seen problems in the past with
>> certain peers, discussed on this mailing-list.  A couple of peers with
>> an empty DB did not help, but one "strange" peer could totally kill
>> things.
> 
>> Looking at http://sks.spodhuis.org/sks-peers now, I see that peers of
>> keyserver.cais.rnp.br, pgp.acm.jhu.edu, pgpkeys.mallos.nl, keyserver.ws
>> and sks.ms.mff.cuni.cz might want to cough at those operators and nudge
>> them to take a look at their servers to see if they're healthy.
> 
> 
> As operator of pgpkeys.mallos.nl, I see it is indeed still 10k keys behind.
> I downloaded the base set of keys 21 Dec '09 and started peering with
> keyserver.gingerbear.net 7 days later (thanks John).
> 
> In my statistics I see a more or less constant rate of 300 to 400 new keys
> added per day. This is about the same keyserver.gingerbear.net is showing,
> so my system cannot catch up and will stay 10k behind. I was hoping a second
> peer would improve this rate, but keyserver.fishysnax.com seems to have died
> soon after it started on 7 Jan '10. OTOH it is only now that I compare the
> two rates and conclude that my system will be behind forever.
> 
> So, yet another call for peers :-)
> 
> pgpkeys.mallos.nl 11370 # Arnold 0xB66BBBAA
> 
> This is a private machine, physically located in the Netherlands (EU).
> The machine has no IPv6 connectivity, yet. For further details visit:
> http://sks.mallos.nl:11371/pks/lookup?op=stats
> http://pool.sks-keyservers.net:11371/pks/lookup?op=index&search=0x642A49C5B66BBBAA
> 
> If it is not in the number of peers, then what can I do further to make it
> sync more quickly?

I have been running the SURFnet server for many years, even before the
Horowitz server, when a Perl script called PGP istself to update its keyring.
The current setup is a dedicated fast SKS server with 8 GB memory. Typically
the server runs for many months uninterrupted until a kernel upgrade requires
a reboot.

The only problem I have every few weeks is Nagios reporting unavailability for
some minutes. Each and every time the service returns without SKS processes
crashing. The reason is *always* other servers, often new ones that need many
updates.

If you are 10k key behind the other servers, 400 keys per day simply means you
either haven't enough hardware or a slow network. 400 updates should happen in
a few minutes.

I am certain many volunteers really try to help the PGP community by adding
more servers. Unfortunately, without real hardware the keyserver community
gets more trouble than help. Reality is that 15 or so fast servers without
slow servers are much better than the current mixture.

cheers,

teun

signature.asc
Description: OpenPGP digital signature