sks-devel
[Top][All Lists]
Advanced

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

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


From: Pete Stephenson
Subject: Re: [Sks-devel] SKS intermittently stalls with 100% CPU & rate-limiting
Date: Thu, 21 Jun 2018 15:11:52 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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

-- 
Pete Stephenson



reply via email to

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