Re: [Sks-devel] SKS intermittently stalls with 100% CPU & rate-limiting

[Moritz Wirth]

I am afraid there is not much you can do about this right now - the pool
itself is very unstable and crashes multiple times per day.

I found over 8 key hashes which cause an Eventloop - this happens every
2-3 minutes, sometimes with the same key, sometimes with other keys. 

Best regards,


Am 22.06.18 um 00:11 schrieb Pete Stephenson:
> On 6/17/2018 12:59 AM, Paul M Furley wrote:
>> Hi Pete,
>>
>>> 2. Is there some countermeasure one can use to protect their server? I
>>> have LimitRequestBody set to 8000000 (8MB) to prevent blatant abuse, but
>>> clearly something is still annoying the server.
>> It appears from Rob's previous email that our servers are failing to
>> synchronise a 22M key (because of settings like this) which is causing
>> sks to continually retry:
>>
>> https://lists.nongnu.org/archive/html/sks-devel/2018-06/msg00014.html :
> It's been four days and my server is still stalling and connections time
> out. The server is regularly being added to and removed from the pool.
>
> I've removed the Apache LimitRequestBody directive in my relevant
> reverse proxy configuration file, but what else can I do to stop this
> continuous cycle such that my server is again a stable member of the pool?
>
>>> 3. Any suggestions on how to deal with the unreasonably high-speed
>>> queries from corporate mail systems? Ideally, they'd run their own
>>> server locally to handle their huge amount of queries, but I have no
>>> real way of communicating that with them. I'd love to slow down their
>>> queries (tarpitting, maybe?) to minimize excess resource consumption
>>> while still answering their queries as opposed to just cutting them off
>>> once they hit a rate limit.
>> Are you sure these users are the cause of your troubles? Or is it this
>> constant-retry loop caused by this large key?
>>
>> I'd suggest contacting them before rate limiting them, ask them to point
>> at the pool or slow down their queries.
> It turns out that contacting them was the right thing to do: they've
> implemented a caching proxy on their end to minimize the load to the
> pool and are looking at running their own server going forward.
> Excellent. Thanks for the suggestion.
>
> Cheers!
> -Pete
>

signature.asc
Description: OpenPGP digital signature