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