[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.
signature.asc
Description: OpenPGP digital signature
- [Sks-devel] Tuning, Christian Reiß, 2014/02/11
- Re: [Sks-devel] Tuning, Tobias Frei, 2014/02/11
- Re: [Sks-devel] Tuning, Jeremy T. Bouse, 2014/02/11
- Re: [Sks-devel] Tuning, Kristian Fiskerstrand, 2014/02/11
- Re: [Sks-devel] Tuning, Daniel Kahn Gillmor, 2014/02/11
- Re: [Sks-devel] Tuning, Kristian Fiskerstrand, 2014/02/11
- Re: [Sks-devel] Tuning, Benny Baumann, 2014/02/11
- Re: [Sks-devel] Tuning, Daniel Kahn Gillmor, 2014/02/11
- Re: [Sks-devel] Tuning, Kristian Fiskerstrand, 2014/02/11
- Re: [Sks-devel] Tuning, Adam Lewicki, 2014/02/11
- Re: [Sks-devel] Tuning,
Benny Baumann <=
- Re: [Sks-devel] Tuning, Jeremy T. Bouse, 2014/02/11
Re: [Sks-devel] Tuning, Jeffrey Johnson, 2014/02/11