Tracking memory usage on WebOS with GnuPlot
Posted by Shane O'Sullivan on October 16, 2011
I’ve been fighting against a serious memory leak in a WebOS app I’m developing, and unfortunately the tools available for WebOS are no help whatsoever for these kinds of problems. There is a program available for WebOS called JsTop, but the data that it tracks doesn’t show that my app is using lots of memory, while at the same time the Touchpad is crashing with the infamous “Too Many Cards” error, with just one card on the screen.
So, I decided to see what I can do about it. A little fiddling with novaterm, grep, awk and GnuPlot has helped me a lot, and hopefully it can help you too.
The image above shows the percentage memory (red) and CPU (green) usage over time of the WebAppMgr process in WebOS, which is essentially where all the apps are executed. To get a graph like this, download the following two scripts (Mac/Linux/Cygwin only):
driveGnuPlotStreams.pl [Source]
You’ll probably have to make them executable, so do:
chmod +x plotWebOS.sh
chmod +x driveGnuPlotStreams.pl
Then plug in your WebOS phone or TouchPad via USB, and run
./plotWebOS.sh
and you should see a graph like the one above. If you don’t see it, it’s likely that you don’t have GnuPlot installed, so Google how to do that for your system, it should be trivial.
For what it’s worth, I get a “Too Many Cards” error just before the process hits 60%, meaning that the other running processes are taking up the remaining ~40% of memory.
If you feel like playing around with this script and doing something else cool, let me know!
Bob said
I remember when I tried to debug a memory leak using top command line. Having it plotted out like this would’ve been much better. Thanks for sharing.
error454 said
The real question is what to do with this data. How does knowing that WebAppMgr is leaky help us? Do we set a threshold and kill WebAppMgr? I reported this behavior back in August when I first got my TP but never received an official response:
https://developer.palm.com/distribution/viewtopic.php?f=91&t=17482
Shane O'Sullivan said
My approach was to disable parts of my app until the memory stopped leaking, then figure out why that part is leaky