On Mon, Dec 14, 2009 at 08:26:09PM +0000, Tim Bunce wrote: > On Mon, Dec 14, 2009 at 03:54:20PM +0000, Nicholas Clark wrote: > > So, at work we have some server processes which are glutons for memory. > > We'd like to work out why, which is tricky. At least, I think that it's > > tricky. > > > > So, I considered what would be the simplest thing that *might* work. > > Devel::NYTProf can measure the elapsed time at a statement granularity, so > > why not use that framework to also measure memory usage? > > You've read my messages in this thread, right?... > http://groups.google.com/group/develnytprof-dev/browse_thread/thread/c711c132216a3cea > > With your more detailed knowledge of the internals I'd be grateful for > any details and observations you could add to that thread. (I'm pretty > sure sme of my assumptions are flawed, I didn't research it in any great > depth.)
Um, I think I read it. "It's hard" and "I can't see a way to do it efficiently" was all I really thought. In particular, measuring elapsed time for a perl OP is a simple, scalar problem. Measuring total memory usage is analogous. Anything more than that is not taking and recording a scalar value, so is in a completely different problem space. I'd prefer to explore the problem space by working out what *is* measurable in practical ways by experimentation. (And this is very much work driven, so experimentation is likely to stop or scale down once we think we've identified the cause of our RAM consumption) > > I've written a malloc() intereception library, > > This seems to work "reasonably" well > > A good solution should be able to account for 'unused' memory in places > like arenas. I thought about this. Right now I wasn't too worried about this, as most every SV type other than undef and numbers allocates more memory via malloc, so I assumed that I'd be able to spot problems via that. The only way I can see to do it efficiently would be to patch the core to track how much memory is allocated to arenas, and how many items of each type. Or, alternatively, recompile perl with -DPURIFY which causes it to use malloc everywhere rather than arenas. Which seemed a much simpler solution. > > Sadly OS X doesn't have LD_PRELOAD, so you have to explicitly link with the > > interception library. > > On OS X you'd use DYLD_INSERT_LIBRARIES. > http://stackoverflow.com/questions/929893/how-can-i-override-malloc-calloc-free-etc-under-os-x The key part seems to be "export DYLD_FORCE_FLAT_NAMESPACE=1", which isn't needed on an ld.so based system. Otherwise, I think, you can only override libraries that you're already actually linked against. So it's not directly analogous (and why I couldn't work it out when I was offline with the Mac laptop writing the code) > > I'm still digetsing whether it actually produces useful-enough results to be > > good at pointing out where memory is going. I'm confident that the > > interception library is recording exactly what *is* allocated. However, I'm > > not sure if this is really that useful a metric for solving actual problems. > > I'd be interested in your post-digested thoughts on this. Any chance you > could post a link to a report? (If your app isn't open source then > perhaps profile some utility that is, like perldoc (small) or perlcritic > (big)). The apps are servers used for work, and sadly most definitely not publishable. I was initially testing by profiling installman. That's definitely open source, and definitely slow. But I don't think I'll have anything to write home about for a while yet. In particular, we know they go bloaty in production, but I don't think that we yet know *why*, or what test data to feed them to replicate this on a development environment. > The addition of your thoughts to the earlier thread would be good, and > help pin down the issues of what's possible and expand the use-cases. > (Perhaps you could, for example, list the kinds of memory allocations > that don't use arenas. Ops spring to mind but I'm sure there are others.) > > Is statement level detail important for memory profiling? > Statement level seems like 'too much detail' to me. I'd have to have some thoughts before I can add them. Although currently I was envisaging total memory profiling at a statement level as a relatively fast way to locate potential points of interest, where more invasive techniques could then be used. > p.s. Is integer byte level detail important for memory profiling? > I was thinking of using doubles instead of ints (so we'd avoid > overflow problems). I suspect that integers are not important. By the time you get to 2**53 bytes allocated, you're not really going to care about the odd byte or two. (2**53 bytes is 8 petabytes. I doubt that Perl 5 programs will get to be that large in the foreseeable future) Nicholas Clark -- You've received this message because you are subscribed to the Devel::NYTProf Development User group. Group hosted at: http://groups.google.com/group/develnytprof-dev Project hosted at: http://perl-devel-nytprof.googlecode.com CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf To post, email: [email protected] To unsubscribe, email: [email protected]
