Hi, everyone, Paul Fontela wrote:
> If nothing has been modified in the configuration of the server or > in the SKS service, what has happened? As others have commented at length, could this indeed be related to malicious or problematic keys? > I have seen that some other servers that are also hosted on Amazon > datacenters are suffering from the same problem, could it be > Amazon, I do not know, I can not answer that yet. The problem is definitely more widespread than Amazon. I am seeing the same issues on my physical server located in Sydney, Australia. My server has plenty of memory and disk space, so that is not an issue (/var/lib/sks/DB is currently 118GB), but one processor core continually goes in and out of being 100% utilised by the single-threaded "sks db" process. I can confirm that I have not changed any major OS component nor the SKS daemon itself--I'm running an up-to-date Debian installation, uptime is currently 48 days, and the problems appeared the same time everyone else's did, just a couple of weeks ago. Happy to provide log files if anyone is debugging; I myself have not spent much time on this, nor looked through the SKS source code. By the way, I tried Phil Pennock's suggestion of removing peers that were significantly behind mine in terms of number of keys, but that made no difference to the situation. Yours truly, John Zaitseff -- John Zaitseff ,--_|\ The ZAP Group Phone: +61 2 9643 7737 / \ Sydney, Australia E-mail: j.zaits...@zap.org.au \_,--._* http://www.zap.org.au/ v _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
