Problem solved (Re: [Sks-devel] Slow syncing)

[Arnold]

Hi,

On 19-02-10 21:28, Arnold wrote:
> On 08-02-10 20:50, Arnold wrote:
>> On 03-02-10 08:15, John Clizbe wrote:
>>> Ryan wrote:
>>>> I had the same issue develop last year, never figured out why but when the
>>>> server was unexpectedly rebooted it came back and started working fine.  I
>>>> recompiled/rebuilt the db, everything and nothing worked, it'd get stuck 
>>>> on a
>>>> loop requesting same keys over and over again never getting anywhere.
>>>>
>>>> I retired the server shortly after this reboot and I have not had any 
>>>> issues
>>>> w/my current setup.
>>> The only time I've seen anything like that recently was a problem that 
>>> looked
>>> like a locking issue on the DB files. I setup DB_CONFIG files in both KDB 
>>> and
>>> PTree and haven't had any problem since.
>>>
> [deleted] 
> I figured the key with hash 1ECBAAC1A284D69B93901F676074D62F seems to be
> missing on my server. To verify, I tried to query that key. Much to my
> surprise, I found the following URL returns the correct key!!!
>  
> http://pgpkeys.mallos.nl:11371/pks/lookup?op=hget&search=1ECBAAC1A284D69B93901F676074D62F
> 
> This key has key ID 0x8523592f. Now the following URL *should* also give
> some result, but is does NOT!
> http://pgpkeys.mallos.nl:11371/pks/lookup?search=0x8523592F&hash=on
> 
> So, I guess my +/- 10000 missing keys are actually in my database, but not
> indexed or so.

So, I did a key dump of my own database, erased the database and build the
database from my own dump.

Statistics when I did the dump: Total number of keys: 2791114
After building from the dump:   Total number of keys: 2801364


So, my system was continuously trying to receive 10250 keys that were
already in the database!

After restarting the servers I fetched 677 keys from a peer, once.

The log below now shows that the server is up to date :-)

Don't know what may have caused it. But I'm happy it's correct now.

   Arnold


2010-02-21 00:25:09 Beginning recon as server, client: <ADDR_INET
195.111.98.30:55383>
2010-02-21 00:25:09 Joining reconciliation
2010-02-21 00:25:10 Reconciliation complete
2010-02-21 00:25:10 No hashes recovered from <ADDR_INET 195.111.98.30:11371>
2010-02-21 00:26:00 Recon partner: <ADDR_INET 76.184.64.189:11370>
2010-02-21 00:26:00 Initiating reconciliation
2010-02-21 00:26:07 Reconciliation complete
2010-02-21 00:26:07 No hashes recovered from <ADDR_INET 76.184.64.189:11371>
2010-02-21 00:26:08 Beginning recon as server, client: <ADDR_INET
195.111.98.30:36322>
2010-02-21 00:26:08 Joining reconciliation
2010-02-21 00:26:08 Reconciliation complete
2010-02-21 00:26:08 No hashes recovered from <ADDR_INET 195.111.98.30:11371>
2010-02-21 00:27:06 Recon partner: <ADDR_INET 83.169.19.225:11370>
2010-02-21 00:27:06 Initiating reconciliation
2010-02-21 00:27:06 Reconciliation complete
2010-02-21 00:27:06 No hashes recovered from <ADDR_INET 83.169.19.225:11371>
2010-02-21 00:28:04 Recon partner: <ADDR_INET 76.184.64.189:11370>
2010-02-21 00:28:04 Initiating reconciliation
2010-02-21 00:28:05 Reconciliation complete
2010-02-21 00:28:05 No hashes recovered from <ADDR_INET 76.184.64.189:11371>
2010-02-21 00:29:04 Recon partner: <ADDR_INET 76.191.185.172:11370>
2010-02-21 00:29:04 Initiating reconciliation
2010-02-21 00:29:24 Reconciliation complete
2010-02-21 00:29:24 No hashes recovered from <ADDR_INET 76.191.185.172:11371>

signature.asc
Description: OpenPGP digital signature