This is a snapshot of the top output of the jmeter process. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31902 root 20 0 11.4g 2.1g 13m S 189.4 17.9 21:13.96 java -server -XX:+HeapDumpOnOutOfMemoryError -XX:+AggressiveOpts -XX:NewSize=1024m -XX:MaxNewSize=1024m -XX:MaxTenuringThreshold=2 -Dsun.rmi.dgc.client.gcInterval
On Wed, Oct 10, 2012 at 3:08 PM, unjc email <[email protected]> wrote: > HI Deepak, > > Thanks for your reply. I don't have any view results tree; "Generate > Summary Result" is the only listener that prints result summary to > screen. > I don't know the jmeter source code inside out, but if you are talking > about the cache map, I believe it holds more than just URLs as it's > the key, the map saves the httpClient object as well. As I mentioned > before, I found that the heap size still keeps on growing even though > I tested with a custom sampler that has the cache map removed. > > FYI, I have a poisoned DNS before the server; therefore, literally, > there could be millions of URLs. > > > Thanks, > Jacky > > On Wed, Oct 10, 2012 at 2: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] >>> >>> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
