Hi On *nix systems you can use kill -3 processid On windows you run in console mode (jmeter.bat instead of jmeterw) and on that window you use ctrl + pause/break. Should print to system.out.
You can also use things like jconsole (but you also need to change the startup for each jmeter) , connect to each instance and see the threads - http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html. Almost all VM monitoring tools can do this as well) - but all usually add a good deal of overhead. I wonder if the pause is because the slaves are returning data to the master. regards deepak On Wed, Dec 14, 2011 at 2:32 PM, Robin D. Wilson <[email protected]> wrote: > I can take a thread dump if someone can tell me how to do it... (Go easy on > me - I'm a manager, no longer a coder...) > > And you were correct, there are no GCs during the 'stop' period on either > the tomcat servers, or the JMeter client box. > > -- > Robin D. Wilson > Sr. Director of Web Development > KingsIsle Entertainment, Inc. > VOICE: 512-777-1861 > www.KingsIsle.com > > > -----Original Message----- > From: Deepak Shetty [mailto:[email protected]] > Sent: Wednesday, December 14, 2011 4:20 PM > To: JMeter Users List > Subject: Re: Strange 'pause' activity during testing > > I think the original post mentioned that GC was not running. > can you take a thread dump when there is a pause and see what the threads > are waiting on? > > > > On Wed, Dec 14, 2011 at 1:56 PM, Kirk <[email protected]> wrote: > > > might be GC.. me be that JMeter's threads are all hung up in your > > server doing stuff. > > > > Regards, > > Kirk > > On Dec 14, 2011, at 10:35 PM, Robin D. Wilson wrote: > > > > > I have a marginally complicated test case that performs a > 'registration' > > on > > > my site. It gets the home page, POSTS a form, gets the response, > > > POSTS another form, gets that response, and then completes. The test > > > runs fine with 100 threads, and 30000 iterations - IF I don't > > > "Retrieve All > > Embedded > > > Resources from HTML Files". In this mode, I am really testing the > > throughput > > > of my 'tomcat' application, not the other elements of my system. > > > (I'm assuming that the other elements are being retrieved from our > > > Content > > Data > > > Network instead of our main system in this case.) > > > > > > If I enable the "Retrieve All Embedded Resources from HTML Files" > > > flag, > > and > > > tune the test down to 10 threads with 3000 total iterations, I > > > notice a > > very > > > strange behavior. The test runs along at a pretty good clip for the > > > first > > > ~600 iterations (about 1 min, 25 seconds into the run), and then it > > > just stops making requests for about 35 seconds. Then, it picks back > > > up again > > and > > > runs for another 1 m 25s, and then stops again for 35 seconds... (NOTE: > > with > > > the 10 threads, 3000 total iterations - but with "Retrieve All > > Embedded..." > > > disabled - I don't see the 'stop' behavior either - so it isn't > > > caused by tuning it down...) > > > > > > I recently added the "Perfmon Metrics Collector" to the test script, > > > so I could see if one of the servers was maxed out - but it looks > > > like all the servers are idle during the 'stop' period. Likewise, I > > > added the Perfmon > > for > > > the "localhost" (running the JMeter test) to see if it was swamped - > > > but > > it > > > too is idle during the 'stop'. I swapped out our network switch (the > > > test environment is on an isolated network switch) with a _much_ > > > higher > > capacity > > > switch - in case there was a network issue, still no change. > > > > > > I'm running out of ideas for things to check - so I thought I'd ask > > > you > > guys > > > if you have any suggestions of things I should look at. > > > > > > My system consists of: > > > > > > WinXP - running JMeter 2.4.1 - driving the test script in GUI > mode > > > Server 1 - running Red Hat Linux, with "Apache (2.2.21)" as > > > the web server - using AJP Proxy to Server 2 > > > Server 2 - running Red Hat Linux, with Tomcat 7.0.21 as the > > > App Server - connecting through Hibernate to Server 3 > > > Server 3 - running Red Hat Linux with MySQL 5.x as the DB > > > Server > > > > > > All 4 machines are running on a private switched network (32Gbs > > backplane). > > > > > > The requests are downloading about 3MB total (per thread per > > > iteration) > > over > > > 4 main URL requests, and 30+ 'Retrieve All Embedded' requests. > > > > > > At first I thought it was the network - but the new switch seemed to > > > deny that thought (the old switch had a much slower backplane). > > > Also, I'm > > having > > > no trouble collecting the PerfMon data during the 'stop' period - so > > > the network is still functioning just fine... > > > Then I thought it might be garbage collection on the tomcat - but I > > watched > > > the gc.log - and it doesn't do any GCs during the 'stop' period. > > > Then I thought it might be the garbage collection on the JMeter > > > side, so > > I > > > started the JMeter.bat from a 'cmd' prompt with gc logging enabled - > > > it doesn't do any GCs during the 'stop' period either. > > > > > > The apache, tomcat, and DB are all 'idle' (no CPU to speak of, no > > > network I/O, no disk I/O, etc.) during the 'stop' period. > > > > > > The JMeter box (WinXP) is doing very little during that time too (I > > > attribute the little bit of activity to displaying the PerfMon > > > graphs, > > and > > > Remote Desktop display to my desktop computer)... > > > > > > -- > > > Robin D. Wilson > > > Sr. Director of Web Development > > > KingsIsle Entertainment, Inc. > > > VOICE: 512-777-1861 > > > www.KingsIsle.com > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - 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] > >
