jpid -l to get the process id of JMeter and then jstack <pid> to get the thread dump. Works on all systems the same way.
If GC isn't running than what you're seeing is that JMeter threads are hung up making server requests. It's a result of the threading model used in JMeter. If you go back to the beginning of summer you can see the Sebb and I had a discussion regarding the challenges of JMeter's threading model.. and why LoadRunner, SilkRunner.. etc use an event driven thread pool based model instead of one thread per user. Regards, Kirk On Dec 14, 2011, at 11:32 PM, Robin D. Wilson 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
