On Tue, Dec 15, 2009 at 11:34:11AM +0000, Nicholas Clark wrote: > 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.
The lessons learnt from your experimentation will certainly be useful. > (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) Understood. > Or, alternatively, recompile perl with -DPURIFY which causes it to use malloc > everywhere rather than arenas. Which seemed a much simpler solution. Yeap. > > > 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) Perhaps not directly analogous, but hopefully close enough to work in this case. (Though I 've not tried it myself yet.) > > > 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. [A side note (wherein I'm probably saying what you already know): One of my favourite tricks for identifying bloaty code is to wait till a process is very big, then get a core file, then 'simply' look for patterns in the core file. I usually start with strings core | sort | uniq -c | sort -rn | less It's amazing how often that reveals the answer, or at least a useful clue. If it doesn't then I'll quickly skim through the core file using less, or similar, looking for repeating patterns of similarly sized gibberish.] > 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. I look forward to your thoughts when they arrive :) Tim. -- 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]
