Hi Chris [lots of snippage]
cb> One of our web apps is using a "lot" of memory, specifically a big cb> user query. We'd like to find out why. cb> 1. Is there a way to analyze uncollected garbage? cb> * AWS EC2 instance. cb> * There are other TC instances on the same server. cb> * Each TC instance has multiple apps. cs> What's the goal? Do you just Want To Know, or are you trying cs> to solve an actual problem. a. Barely enough memory to distribute among the multiple TC instances and the apps they support. A big enough user query (no throttling) causes OOME's. Attempting to determine if the code is being wasteful in some way and therefore could be made more efficient. b. It's a dev app server (EC2) which hosts diff stages in the dev process - dev, test, and prototype streams. Multiple TC instances (3) because multiple copies of the apps don't play nice with each other. That is, we can't just rename the WAR files and expect the deployed apps to stay inside that context name (I think). c. I don't want to debug the code. I'm relatively new to the project, unfamiliar with some of the code, and anticipate getting lost in the weeds. See point #1 below. ;-) cs> If you have a bunch of garbage that's not being cleaned up, cs> usually it's because there is simply no need to do so. The GC cs> is behaving according to the 3 laws of rob..., er, 3 virtues of cs> computing[1]: cs> cs> 1. Laziness: nothing needs that memory so... meh cs> 2. Impatience: gotta clean that Eden space quick cs> 3. Hubris: if I ever need more memory, I know where to find it cs> [1] http://threevirtues.com/ Ha ha ha! :-) cs> How long does the query take to run? Dunno about the time on the DB query itself. From the user's point of view, a full minute plus. cs> What kind of query is it? Are we talking about something like SQL Yup. Classic RDMS back-end. cs> or some in-memory database or something which really does cs> take a lot of memory for the application to fulfill the request? Nah, nothing that fancy. The only fancy part is using node.js for the front-end. I followed Amit's and John's suggestion of using Eclipse Memory Analyzer Tool's "Keep unreachable options" when running a query from the app client. Digging deeper into the Leak Suspects Report, I saw a StringBuilder - 264MB for the supporting byte array and 264MB for the returned String, about 790MB total for that piece of the pie. Contents were simply the JSON query results returned to the client. No mystery there. I suspect that repeating the process with multiple queries will reveal multiple StringBuilder's each containing big honking JSON results. So the issue may not be a problem with efficiency so much as one of simple memory hogging. (At least StringBuilder is being used instead of plus-sign String concatenation.) -- Cris Berneburg CACI Senior Software Engineer ________________________________ This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
