On Apr 13, 2011, at 7:55 AM, Sebastian Wiesinger wrote: >> >> An update of 5000-1000 keys over 2-3 hours isn't wildly out of line >> with the statistics I've seen. > > I don't know if it is a problem, it's just something I would like to > avoid if possible. It gets the server load up and causes I/O wait. >
Well I/O wait is an intrinsic problem, while the size of the update is an extrinsic issue. So let's deal with "I/O wait" as the problem. >> Key servers come and go, and when there's a diconnection of some sort, >> then there can be a burst of activity when the disconnection repairs itself. >> >> That is the nature of gossip proptocols. >> >> Is there a real problem here? What is the problem? > > Again, I don't know if it is a problem but it's unusual at least. I > don't know about you but I want to know the reason why a program is > suddenly using a high amount of resources on my server. > Sure, perfectly understood. What is in your DB_CONFIG file? Have you tuned Berkeley DB? My DB_CONFIG looks something like what is attached. Note that there are other possible causes of "I/O wait", but Berkeley DB is in the engine room, so its a reasonable place to start looking. 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 # ================ 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel