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 without an initial DB behind it > 5 sudden really *really* heavy query load
I think you're missing another possibility:
6 sks recon might leak memory during regular operation
Just observing the pattern of memory usage since i did the sks restart
on zimmermann, it seems to be steadily climbing. An hour after sks
recon had an RSS of < 5000KB, it is now at 7840K.
It was at 3GB when i restarted, but the process had been running without
interruption since 2008.
Maybe someone who knows the source and/or is proficient with the use of
valgrind could assess whether sks recon is actually leaky?
FWIW, zimmermann is running sks 1.1.0-4 from amd64 debian GNU/Linux (lenny).
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/sks-devel
