[Top][All Lists]
[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
smime.p7s
Description: S/MIME Cryptographic Signature
- Re: [Sks-devel] Big amount of updated keys yesterday?, (continued)
Re: [Sks-devel] Big amount of updated keys yesterday?, Kim Minh Kaplan, 2011/04/13
Re: [Sks-devel] Big amount of updated keys yesterday?, Jeff Johnson, 2011/04/13
Re: [Sks-devel] Big amount of updated keys yesterday?, Daniel Kahn Gillmor, 2011/04/13
Re: [Sks-devel] Big amount of updated keys yesterday?, Jeff Johnson, 2011/04/13
Re: [Sks-devel] Big amount of updated keys yesterday?, Andrey Korobkov, 2011/04/24