Okay, I have no desire to start (continue?) a flame war here. I personally have a need to see the actual memory usage of my application, to check for leaks. I thought it might be a common need, and since I'd already written the code, I might as well "give back".
Yes, I know how Java "memory leaks" work. In web apps, they're generally when someone binds a large object (or many small ones) to app context, or to a background processor thread that doesn't die in a timely fashion. I tend to first worry about the memory usage of my application before I start blaming the system heap allocation. I've been writing Java web apps since before JSP's, before the term J2EE was coined, back when we wrote 1000-line Servlets and we LIKED it. ;) I've used many other Java stress-testing and profiling tools. My current employer is too cheap to buy us a commercial product, so I'm using JMeter instead. What I sent was a user request. Hostility to user requests affects usability and prevents free software from fulfilling its potential. This is the last you'll hear from me on the matter. On 8/18/05, Peter Lin <[EMAIL PROTECTED]> wrote: > Here is an article that might provide some useful information. > > http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&detailArticle=true&id=9606 > > Also keep in mind that other JVM like JRockit do not have PermGen for > static classes. So things like setting PermGen do not apply to > JRockit. IBM's JDK also handles GC a little differently. > > it's actually very common to get OOME, even though the system has > plenty of memory. I've seen cases where the max heap is set to 1GB, > but tomcat got OOME because the JVM couldn't increase the heap fast > enough. these kinds of cases are typically 3-5x increase in load. > > peter > > > > On 8/18/05, Jonathan Oexner <[EMAIL PROTECTED]> wrote: > > My concern with the current used /current heap line is that, if the VM > > decides to increase the heap size, you can't tell by looking at the > > line whether heap size went up, or the GC freed up some memory. > > > > The rationale behind using the max heap size as the denominator is > > just so that the memory used line depends *only* on the amount of > > memory in use (well, that and the *max* heap size, which is constant > > for our purposes). You can see the absolute heap usage. It has the > > added benefit that both the heap size and the heap usage are on the > > same scale, which means that you can see how close the memory usage > > has to get before the JVM decides to grow the heap. > > > > Try it out. You might like it. ;) > > > > On 8/18/05, Peter Lin <[EMAIL PROTECTED]> wrote: > > > yeah, the load line is totally synthetic. honestly, I don't know which > > > approach is best. I tend to think of things a certain way, which is > > > based on work experience. I think adding an additional line might be > > > good. what about > > > > > > current used /current heap > > > current heap / max heap > > > > > > for what I do, the heap rbehavior is a better indication of > > > application performance. under constant load, the line would show a > > > regular pattern. A poorly written app would show erractic heap usage, > > > which indicates a potential problem. For example, I tend to profile > > > my webapps for 1million requests and see if the thread and memory > > > usage reach a regular pattern after a few hours. If it doesn't, I > > > profile it with OptimizeIt and track down the issue. I probably won't > > > have time to work on it this week, but next weekend I may have time. > > > > > > peter lin > > > > > > > > > > > > On 8/18/05, Jonathan Oexner <[EMAIL PROTECTED]> wrote: > > > > Hi Peter, > > > > > > > > It seems to me that we're trying to force this one status line to do 2 > > > > jobs. Maybe we need a usage line (current usage / max heap) *and* a > > > > current heap line (current heap / max heap). Coincidentally, the > > > > "Load" line seems a little, umm, "synthetic" anyway, so maybe we could > > > > swap it out and add a line for heap size. When the yellow line tries > > > > to cross the blue line, your app will flatline. ;) > > > > > > > > I'm actually graduated from WPI (note the "alum"), and using JMeter to > > > > earn my keep from the Man. > > > > > > > > On 8/18/05, Peter Lin <[EMAIL PROTECTED]> wrote: > > > > > thanks for the feedback. > > > > > > > > > > On 8/18/05, Jonathan Oexner <[EMAIL PROTECTED]> wrote: > > > > > > Hi all, > > > > > > I'm just getting started with webapp performance testing with > > > > > > JMeter, > > > > > > and I noticed the bug mentioned in the thread 'Possible bug in > > > > > > monitor > > > > > > results listener' from late last year, still present in release > > > > > > 2.0.3 > > > > > > . I downloaded the nightly 2-1.20050812, only to find that the bug > > > > > > "fix" in CVS is still a little off. The memory usage that most > > > > > > people > > > > > > want to see (IMHO) is: > > > > > > > > > > > > current usage / maximum available > > > > > > > > > > > > as opposed to: > > > > > > > > > > > > current usage / current heap size > > > > > > > > > > > > > > > > > > They don't really care what the JVM is doing to the current heap > > > > > > size; > > > > > > they just want to know the absolute usage, and how close the are to > > > > > > an > > > > > > OutOfMemoryError. Additionally, since the *currently allocated* > > > > > > heap > > > > > > size will change whenever the JVM decides to change it, using it for > > > > > > the denominator makes it very hard to get an idea of the actual > > > > > > usage. > > > > > > I'm much too lazy to submit an actual patch, but in > > > > > > $JMETER_HOME/src/monitor/components/org/apache/jmeter/monitor/util/Stats.java > > > > > > , I changed the two methods below, and the results make a whole lot > > > > > > more sense this way. > > > > > > > > > > In practice this is not true. In most cases, a server will crash > > > > > before it reaches the max heap size. I tested tomcat about 2 dozen > > > > > times with a wide variety of loads. I actually started with the > > > > > assumption that max heap was better, but after I ran some tests, it > > > > > became apparent that wasn't true. > > > > > > > > > > if you were to profile tomcat with verbose GC you would see that often > > > > > an application runs out of memory because the JVM is unable to resize > > > > > the heap fast enough. this typically happens with a sudden traffic > > > > > spike occurs. Under steady constant or semi-constant load, current > > > > > usage / current heap is also more accurate. Say for example I set my > > > > > max heap to 512Mb. If constant load uses 200, using the max heap > > > > > won't tell me much. In fact it will give me a false sense of security. > > > > > > > > > > also, using the current used / current heap lets you see how the JVM > > > > > is resizing the heap and indicates if there is a memory. Several > > > > > tomcat developers use Jmeter monitor for that purpose and so do I. If > > > > > you don't believe, I would suggest changing it and run 20-30 tests > > > > > with varying request rates and thread count. > > > > > > > > > > I noticed you're attending Worcester Polytech. Are you doing this for > > > > > a degree? > > > > > > > > > > peter lin > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
