sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] Big amount of updated keys yesterday?


From: Teun Nijssen
Subject: Re: [Sks-devel] Big amount of updated keys yesterday?
Date: Wed, 13 Apr 2011 15:11:43 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9

Hi,

fwiw, pgp.surfnet.nl runs

set_flags DB_LOG_AUTOREMOVE
set_flags DB_TXN_WRITE_NOSYNC
set_cachesize 0 67108864 0
set_lg_bsize 33554432
set_lg_max 134217728

cheers,

teun

on 2011-04-13 14:56 Jeff Johnson wrote the following:
> 
> On Apr 13, 2011, at 8:40 AM, Jeff Johnson wrote:
> 
> I should underscore where to fix "reliability" issues,
> and where to try for "performance"
> 
>>
>> Caveat:
>> I spend way too much time fussing with Berkeley DB issues (in RPM) to try
>> to tune SKS keyservers for absolute maximum performance. So take the above 
>> values as
>> nominal and "gud ebuf" rather than any serious attempt to tune for 
>> performance.
>>
>> hth
>>
>> 73 de Jeff
>> ==========================================================================
>> set_lg_dir              ./log
>> set_tmp_dir             ./tmp
>>
>> set_flags               DB_LOG_AUTOREMOVE
>>
>> # -- thread_count must be >= 8
>> #set_thread_count        64
>>
>> # ================ Logging
>> set_lg_regionmax        1048576
>> set_lg_max              10485760
>> set_lg_bsize            2097152
>>
>> # ================ Memory Pool
>> ##set_cachesize         0 67108864 4
>> set_cachesize           0 134217728 1
>> set_mp_mmapsize         268435456
>>
> 
> The above 2 are the main "performance" tunables. mmapsize in
> particular is quite important: if you have the memory, use it,
> and mmap(2) used by Berkeley DB is fastest. I've personally never
> seen too much performance gains tuning cachesize (but all depends on
> the types of access, my experience is with RPM, not SKS, stores so YMMV,
> and almost certainly WILL vary).
> 
> There's a pagesize tunable too, but I doubt that will help seriously
> with tuning SKS because the records are too small. Changing the pagesize
> also changes the locking granularity (BDB locks are per-page) so you
> likely will also affect "reliability" if you change the pagesize.
> 
> 
>> # ================ Locking
>> set_lk_max_locks        4096
>> set_lk_max_lockers      4096
>> set_lk_max_objects      4096
>> set_lk_detect           DB_LOCK_DEFAULT
>> mutex_set_max           163840
>>
> 
> These are the main "reliability" tunables that MUST be increased for
> an SKS keyserver, the defaults aren't anyplace close to being able to
> handle a ~3Gb store like in SKS keyservers.
> 
> I typically just double the values until a problem goes away, and
> scale "mutex_set_max" as ~10x the size of the other values. I
> can tell from the settings above that I was (rather idly) looking at
> the minimum locks needed for a SKS keyserver because the numbers don't
> follow my usual heuristic of
>       mutex_set_max is ~10x the value of "set_lk_max_locks"
> 
> hth
> 
> 73 de jeff
> 
> 
> 
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/sks-devel


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

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