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

[Jeff Johnson]

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