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 > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
