sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] 1.0.5 released


From: Dan Egli
Subject: Re: [Sks-devel] 1.0.5 released
Date: Mon, 01 Dec 2003 12:32:48 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3

Peter Palfrader wrote:

On Mon, 01 Dec 2003, Dan Egli wrote:

Peter Palfrader wrote:

On Mon, 01 Dec 2003, Peter Palfrader wrote:



On Sun, 30 Nov 2003, Yaron M. Minsky wrote:

I released 1.0.5 onto the savannah site.  I did manage to get support
for revocation keys in at the last minute.  If you're starting a new SKS
server, you should definitely use 1.0.5, since it provides indexing of
subkey keyids.
Will subkey indexing magically work after upgrading, or is more action
required?
Some progress indicator for update_subkeys would have been nice.  It
seems to take ages :)
Are you sure you grabed the tarball and not a CVS version? I know it takes a couple of hours, but still, it should not take THIS long I'd think. I'm wondering if you've deadlocked your database. You DID shutdown all instances of sks, sks_db, sks_recon, etc...BEFORE running update_subkeys didn't you?

Yes, everything was shutdown prior to running update_subkeys, and I use
the released tarball.  I started the update at 10:00:14, and now (at
19:40) there are about 1 500 000 keys processed (as indicated by the
log.  150 times "10000 updates found.  Applying to database").

I have no idea what is slowing it down that badly, but there is plenty
of CPU left, plenty of RAM left and the swap used stays very much
constant (i.e. not trashing) and I don't think that my disks are _that_
slow.

Peter
Well updating the database is a long process because it has to scan every key in the database, find any sub keys to that key, and add them to the subkey database and index. It's nearly the equivalant of rebuilding the database from scratch.

When I had to rebuild my DB most recently, it took around 11 hours. Low memory usage, near 0 swap change (I watched /proc/meminfo), only moderate processor usage, but took around 11 hours.

If it's showing about 1.5M keys processed it's almost done. The current count of keys in my DB as of my last check (couple of days ago) is approx 1.9M, so you only have 400K to go. At 10k per run, it's another 40 runs.

--- Dan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]