ferd
Would atom table dumping be useful for recon?
See the second answer here http://stackoverflow.com/questions/13480462/erlang-can-i-get-a-list-of-all-currently-registered-atoms It's a neat trick which could of course break an any point, but I could imagine something which captured the current count, paused, then captured again helping out in the cases where you are programmatically creating atoms (or something is), and you don't know what.
Assumably, the system might first crash with full atom tables or something like that, they you start up with recon and see what's growing the table? At least that's a use-case I could imagine.
What do you think?
Actually someone at Klarna suggests trying this as well https://engineering.klarna.com/monitoring-erlang-atoms-c1d6a741328e (I'm clearing out old tabs and these were next to each other, I just sent them in the wrong order ;). I'd be willing to make a pass at the code, but just wanted your opinion on it's usefulness before I do.
I've never really seen the use too much for it, but it could make sense to allow this functionality.
If I had to build it though, I'd likely set it to return the N newest atoms in the table only (with maybe a type like pos_integer() | all so you can get the whole table, but you have to make it explicit). If you're noticing a leak, it's unlikely the atoms near the beginning of the table are to blame, given they'll be based on code and static, but those at the end of the table are all likely to be dynamic.
Yeah, I technically haven't needed it, but figured since I put recon onto all my systems if I ever did need it recon would be the place for it. I guess the real issue is finding the end of the table. With 20 one could use the atom_count stat, then use the external term format trick. For pre-20, the function from the klarna blog post could be used. I'll probably tinker with it and send along a PR at some point.
An alternative approach would be to do the standard binary/exponential search: 1024,2048,4096,... until it fails, and then do binary search on the slice. Not sure if it would be faster than parsing the ~50kb or so of system info. Possibly slower, eh.