On 02/13/2009 10:21 PM, Phil Pennock wrote:
Normally, sks consumes a negligible amount of the resources on my
server; some GB of disk, some MB RAM (~45 right now, after restart), not
enough network that I've bothered to isolate figures for it.
I just found that my box was thrashing badly
On 2009-02-14 at 16:50 -0500, Daniel Kahn Gillmor wrote:
Yikes! Thanks for pointing that out, because you made me check up on a
keyserver i'm responsible for. It looks like zimmermann.mayfirst.org
is doing the same thing. the sks recon process in particular now has an
RSS of 3.3g.
:-(
On 02/14/2009 05:24 PM, Phil Pennock wrote:
So, the options behind it, if the correlation is more than coincidence,
seem to be:
1 bad SKS update
2 bad query hitting pool.sks-keyservers.net
3 someone hitting the servers individually deliberately
4 someone doing full sync of a keyserver
I've been having terrible corruption issues (need to run reconstruction every day), as I
usually notice with bdb-based applications. I was wondering if anyone has experimented
with patching sks to use something more reliable like mysql, postgres, sqlite, etc?
mysql and postgres are
On 2009-02-14 at 17:45 -0500, Daniel Kahn Gillmor wrote:
Maybe someone who knows the source and/or is proficient with the use of
valgrind could assess whether sks recon is actually leaky?
I had been running without *noticing* any increase for some time and am
inclined to believe that it's a
On Feb 14, 2009, at 3:59 PM, Alex Roper wrote:
on issues (need to run reconstruction every day), as I usually
notice with bdb-based applications.
In defense of BDB, I have written a multi-process application (in C)
that handles billions of transactions per year, and I have never
That would be nice. Personally I always use a database abstraction layer of some kind so
it's easy to choose your backend. As I mentioned, mysql and postgres would be a far
cleaner setup for us in particular, and I'd like to see that here.
Joseph Oreste Bruni wrote:
On Feb 14, 2009, at 3:59
