Hi its more likely that you have some listener turned on (like view results tree) - Even if a URL is 2000 characters you can calculate how many URLs before you use up say 100MB of memory. Do you really have that many URLs even if they are dynamic? http://jmeter.apache.org/usermanual/best-practices.html#lean_mean
regards deepak On Wed, Oct 10, 2012 at 9:21 AM, unjc email <[email protected]> wrote: > Hi all, > > I have memory and cpu issues when running heavy load testing with > HTTP(S) sampler. The purpose of my test is to hammer the server as > fast as Jmeter can, using a big list of hostnames and URIs, via a > proxy server. The test plan I have setup is configured with > 100-thread thread group that contains a HTTPS Request sampler (using > HTTPClient4) and Summary Results generator. > > The machine I am using has 12GB memory and 16-core cpu. I monitor the > top output throughout the test. I notice the RES size of the jmeter > java process is growing really fast - it reaches 2GB heap size limit > in less 5 minutes. The test could never go beyond 30-minute mark > without OutOfMemory exception. I know there are plenty of free memory > for me to expand the heap size; but my concern is whether there is a > memory leak in the code. I worry the process would suck up all > available memory anyway if I run a stress test for a day or longer. > > I have skimmed through the code of HTTPHC4Impl and found that there is > cache "map" for HttpClient with regard to URL. I suspect this cache > map could go pretty crazy in tests that deal with large number of (or > dynamic) URLs. Just curiosity, I tried running a test with using a > custom sampler as like HTTPHC4Impl but without the cache map; it seems > help slowing down the pace of the heap size. However, the heap size > (RES size in top output) never seem settle at one level over time. > > Does anyone have any experience in running similar test as I do? Does > it look like a potential "memory leak" to you? Any comment or advice > will be appreciated. > > > > > Thanks, > Jacky > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
