sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Tuning


From: Benny Baumann
Subject: Re: [Sks-devel] Tuning
Date: Tue, 11 Feb 2014 20:49:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Hi,

Am 11.02.2014 20:19, schrieb Daniel Kahn Gillmor:
> On 02/11/2014 01:58 PM, Benny Baumann wrote:
>> Am 11.02.2014 16:59, schrieb Kristian Fiskerstrand:
>>> Unless you run it in a clustered setup where the different members
>>> calculate it on different times and the frontend passes the request on
>>> before timeout :p
>> Its almost instantly for my maschine ...
> what is almost instantly, Benny?  Are you saying that the stats
Usually below 5 seconds; thus after restarting the service and switching
to the browser I already get useful stats.
> calculation returns almost instantly?  If so, i wonder why there is such
> a variation.  How much RAM is available for your machine?  what other
8GiB RAM available total; 3 GiB usually used, rest ist available as disk
cache.
> contention do you have for disk I/O?  What kind of disks are you using?
RAID1 with two disks. Although before updating the DB settings I hardly
got SKS keep up with usual load.
>
> On a pretty decent machine (zimmermann.mayfirst.org), i'm seeing the
> following duration in the logs:
>
> 2014-02-11 19:17:17 Calculating DB stats
> 2014-02-11 19:17:49 Done calculating DB stats
>
> so that's over half a minute of blocked access.
2014-02-11 20:12:16 Calculating DB stats
2014-02-11 20:12:44 Done calculating DB stats

Core i7, 8x2.6GHz
>
>> IMHO better include a line "updated last at $TIME taking $DURATION seconds.
> I like this proposal.
>
>> Given most servers update their stats at different times and the number
>> of keys you are allowed to lag behind being quite small it's more an
>> issue of the stats misrepresenting a keyserver which would actually be
>> just fine. Either you would need to update the stats for the pool just
>> once a day OR update stats on the individual servers more frequently so
>> information isn't lagging behind. 
> I'm not sure what you mean "update the stats for the pool".  Do you mean
> "update the key size limit" or "check on the stats reported by each
> keyserver" or something else?
Keep the pool update the server details every hour while also asking the
SKS instances to do their stats more frequent (like every 2-6 hours).
People who can't affort the resources then could just keep at once every
day.
>
>> I'd advocate for the second option to
>> update the stats on the various servers more often as this should reduce
>> the fluctuation due to outdated stats pretty good.
> If the cost of stats generation was close to zero, i'd agree with you.
> But that's not what it looks like to me.   If stats generation is
> expensive (and blocking), then increasing the regular frequency of stats
> generation would mean more frequent failures of systems already in the
> pool (since they don't have a way to remove themselves from the pool
> during the time they are generating stats).
>
>       --dkg
>
What about moving the stats update into recon?

Regards,
BenBE.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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