Hi im curious what did you open this dump in (I get invalid hprof version on Mem Analyzer in eclipse) Does this caching apply only to HTTPClient based samplers or even the other HTTP Request?
regards deepak On Thu, Oct 11, 2012 at 5:07 AM, Philippe Mouawad < [email protected]> wrote: > Hello, > I looked at your heap dump, it seems you are load testing lots of > differents WEBSITES (I mean HOSTs are all different). > This is clearly a very "weird" use case that we don't handle for now, and I > am not sure we will. > > Regards > Philippe > > > On Thu, Oct 11, 2012 at 12:10 AM, unjc email <[email protected]> wrote: > > > I have uploaded the heap dump file online and it's available at > > http://dl.free.fr/qZBPvLRB8. > > > > > > > > Thanks, > > Jacky > > > > On Wed, Oct 10, 2012 at 3:20 PM, Philippe Mouawad > > <[email protected]> wrote: > > > Hello, > > > Which map are you talking about in HTTPHC4Impl ? > > > > > > If it's this one: > > > > > > - Map<HttpClientKey, HttpClient> map = HTTPCLIENTS.get(); > > > > > > Then it only exists once per thread and per combination of : > > > > > > - url.getProtocol()+"://"+url.getAuthority(); > > > this.hasProxy = b; > > > this.proxyHost = proxyHost; > > > this.proxyPort = proxyPort; > > > this.proxyUser = proxyUser; > > > this.proxyPass = proxyPass; > > > > > > so unless you change these per url , it won't grow a lot. > > > > > > Check what Deepak is suggesting and if issue persists, then generate a > > Heap > > > Dump and put it somewhere where we can download it. > > > > > > Regards > > > Philippe > > > > > > On Wed, Oct 10, 2012 at 8:53 PM, Deepak Shetty <[email protected]> > > wrote: > > > > > >> 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] > > >> > > > >> > > > >> > > > > > > > > > > > > -- > > > Cordialement. > > > Philippe Mouawad. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > Cordialement. > Philippe Mouawad. >
