Eye on Performance: Profiling on the Edge
By Jack Shirazi & Kirk Pepperdine2005-04-21
A Trip to the Fat Farm
|
|
Recently we were given the assignment to reduce the memory footprint of a fat client. While the term "fat client" often is used to mean an ordinary GUI client application, in this case the client was nearing obesity. This client was running on the Windows platform, which imposes a limit on process size of 2 GB. After subtracting the executable address space and other spaces needed to include various JNI products, the maximum heap size available to the application was around 1.2 or 1.3 GB. Unfortunately, some of the users of this application were getting very close to that limit because of the volume of data they were pouring through it. One obvious tuning option was to move to Unix machines, but that was ruled out as impractical -- the customer preferred instead to slim down the application.
So, our task was set. Profile the fat client and find out what was taking up all the space. Then slim down some of those objects to a size that left headroom for later expansion or higher data volumes. Straightforward, we thought. It might take a while of course, because object reduction is usually more of a long slog than leaps of brilliance, but in a heap of that size there must be lots of extra flab that could be cut. Or so we thought.
The usual procedure
We began our usual footprint-reduction procedure: set up the test environment, specify a reproducible test, fire up the profiler, run the test, analyze the data, and look for tuning opportunities. Tick follows tock, we do this all the time . . . or so we thought. This time, we got to the "run the test" step, and the profiler fell over. So we tried again. And it died again. We changed the configuration of the profiler to minimize the overhead it needed and tried again. And it died again. There was simply not enough JVM heap space left over to accommodate the profiler for the entire run, let alone generate any useful profiling data. And we were using a classy, commercial profiler, usually very reliable, so we were surprised.
Try, try again
Well no matter, there are plenty more fish in the sea, and nowadays there are plenty more profilers to choose from (see Resources for a recent review of available profilers). Another day, another profiler, right? The sequence of testing was, unfortunately, remarkably similar. Profiler number two crashed the JVM at about the same point that profiler number one did. It was even highly configurable, like profiler number one, and configuring it to minimize overheads and data extracted from the profiles got us that little bit further. Just like profiler number one. And it crashed. Just like profiler number one. Profiler number three was, sadly, no different.
A cunning profiler
Profiler number four, however, was cunningly different. For memory analysis of a snapshot of live objects (ignoring object creation and garbage collection, and only looking at a snapshot of live objects at some point), profiler number four imposed no overhead at all on the JVM until the snapshot was required. Success! For the first time, our test ran through to the point where we needed to take our snapshot, with the profiler running. We were happy. Then we triggered the snapshot, and the JVM crashed.
We tried it again, but the profiler needed too much extra process space to generate the snapshot. It just wouldn't work. We were back to square one! There were still half a dozen more commercial profilers we could try, but the pattern was obvious. It was time for some lateral thinking.
Ironically, it was the sophistication of the profilers themselves that was our problem. We needed something simple. Of course, simple doesn't always mean lower overhead, but it was worth a try, given the disappointing results we'd had so far with sophisticated profilers. So we started scanning through the open source profilers.
Tutorial Pages:
» What do you do When Your Tools are Too Fat?
» A Trip to the Fat Farm
» Back to the Beginning
» Simple But Ugly
» The Final Word
» Resources
First published by IBM developerWorks
|
