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 change in observed behaviour. I saw recon size go to 3GB again, but the RSS was only 11MB, so not so painful. Thus I'm inclined to think that most of this is DB backing (/pending/sks/PTree/ptree mmap'ing) and therefore mostly not paged in and harmless. So, what has changed the working set? In trying to visit my peers' stats pages, one has no data (DB recent restart) and one has ... 25503 keys. However, I added that peer in November, shortly after I myself set up my server. So unless bazon.ru only recently lost its keys, that looks less likely. I begin to wonder if recon is sub-optimal with a large delta of keys to send and also to wonder if I should bump "learn to read OCaml" up my priority list -- I'm managing to navigate the sks source faster already, but I'm still mostly in the dark. I'm fairly sure that the only other recentish change in my setup is innocent; I set up db_recover to run weekly, but that's on a Saturday and since I didn't set $PATH to include the tools, automatic runs wouldn't work until I fixed that today so it has only happened the first time when I wrote the wrapper script and I restarted the DB server shortly thereafter anyway because I'd played with sks dump before discovering that it couldn't be done online. -Phil
pgp3T8Rj3PrAo.pgp
Description: PGP signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel