Thanks for the help everyone! After tweaking and playing around with some stuff, I was able to run my tests the way they should.
I found that one of the problems was the proxy which seemed to delay the requests in sort of a random fashion at large volumes. In addition, the main thing I changed is increasing the load much slower, so add 25 threads per 10 secs instead of 100 threads per 5 secs. Both JMeter and and the proxy seem to respond in a more 'natural' way to this. Now let's hope my other test cases will run smoothly after this. Thanks again everyone :) CP -----Original Message----- From: Anthony Johnson [mailto:[email protected]] Sent: woensdag 30 maart 2011 23:29 To: JMeter Users List Cc: Kirk Subject: Re: Out of memory almost immediately after start Hi Kirk, Java heap allocations will fragment the C Heap. PermGen memory will fragment the C Heap. JIT Compilations will fragment the C Heap. Java Thread creations/destruction will fragment the C Heap. PermGen and Java Heap I can do something about. Sorry, but my answer is still that for a memory intensive application you should be setting your memory settings properly to get the most out of your 32 bit memory space. When setting the -Xms -Xmx to be the same at startup, I get 2-3 very clean 1GB memory allocations in my process memory space. If you don't set -Xms, then your process memory space is littered with smaller memory allocations over the course of the process runtime. If your blog doesn't tackle why keeping my memory space ultra clean is a bad idea then it will not win me over. We are both entitled to our opinion:-) I don't think we need to continue to hi-jack this thread any further. Hopefully the parent resolved his issue. Thanks, Anthony On Tue, Mar 29, 2011 at 6:34 PM, Kirk <[email protected]> wrote: > Hi Anthony, > > Setting ms to mx is a tuning/configuration mistake in most cases. I have a blog entry that explains this (Keep your hands off of the switches iirc) and I've another one in the pipe that very clearly exposes why you should rarely set mx == ms. > > Java heap is taken from C heap. C heap is stacked on the back of stack space in Windows and Linux. That means stack and text areas are fixed in size at startup. If by native memory you are talking about C heap, then point taken. That said, most Java applications should not require a lot of native space unless they are using direct byte buffers (aka the newest version of EHCache) or objects that create structures in C heap (eg. file/socket descriptors). > >> >> The fact that the 10th thread gets an error and thread creation is >> fine after that does sound like some sort of OS or Java bug as sebb >> mentioned. Hopefully the parent can make sure that he is using the >> most recent JVM and see if the problem still occurs. > > This is a strange one for sure. I'd be looking in the bug database to see whats going on. One of the things that sometimes happens is that problems with the LD_LIBRARY_PATH case the JVM to be constructed with the wrong versions of shared libraries. Though normally this causes the JVM to core dump, I guess it could cause other (strange) behaviors in the JVM. > > Regards, > Kirk > > > --------------------------------------------------------------------- > 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]
