I am observing the following issue while running a JMeter script from non GUI command through Jenkins pipeline.
The JVM should have exited but did not.
The following non-daemon threads are still running (DestroyJavaVM is OK):
Thread[AWT-EventQueue-0,6,main], stackTrace:sun.misc.Unsafe#park
java.util.concurrent.locks.LockSupport#park at line:175
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#await at line:2039
java.awt.EventQueue#getNextEvent at line:554
java.awt.EventDispatchThread#pumpOneEventForFilters at line:187
java.awt.EventDispatchThread#pumpEventsForFilter at line:116
java.awt.EventDispatchThread#pumpEventsForHierarchy at line:105
java.awt.EventDispatchThread#pumpEvents at line:101
java.awt.EventDispatchThread#pumpEvents at line:93
java.awt.EventDispatchThread#run at line:82
Thread[AWT-Shutdown,5,system], stackTrace:java.lang.Object#wait
sun.awt.AWTAutoShutdown#run at line:314
java.lang.Thread#run at line:748
Thread[DestroyJavaVM,5,main], stackTrace:
java.awt stands for Abstract Window Toolkit, you should not be seeing this form of messages given you run JMeter in command-line non-GUI mode.
I can only think of a bug in JMeter like 64479 so if you have a HTTP(S) Test Script Recorder in your test plan - try removing it completely.
Other things to try:
set jmeterengine.force.system.exit=true property in user.properties file
make sure to follow recommendations from the 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article so your JMeter instance will be properly configured for high loads as JMeter's default settings are suitable for tests development and debugging but not sufficient for more or less immense load
Related
While running the script in non-gui mode for jmeter tests, test gets completed but it does shows min: 0, max: 0...
note:
JMeter 5.4 is installed without any 3rd party plugin.
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)
Please help
It means that none of Samplers were executed and the reasons could be in:
The number of threads in Thread Group is 0
The test contains CSV Data Set Config and the .csv file is not there
The test relies on a JMeter Plugin which is not installed
etc.
The reason should be in jmeter.log file, check it and I believe you will find either the cause or at least a clue there.
Also be aware that according to 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article you should always be using the latest version of JMeter so consider upgrading to JMeter 5.4.1 (or whatever is the latest stable version available at JMeter Downloads page) on next available opportunity
I guess you probably found the answer - but maybe this response will be useful to someone.
I've been battling a similar issue -> locally all was working fine (in GUI and non-GUI mode), but as soon as I tried to run the jmx on the server I could see it would start threads, all logs seemed normal (standard info logs within jmeter.log at start) but still no requests were actually made (confirmed by observing logs from the target server). I tried running trace logs but still nothing out of the ordinary - I could see proper HTTP config, threads were as if normal... But the generated jtl file only contained a header and no requests actually were made.
After some hair pulling I finally found my issue - I'm using variables for threads, rampup and loop which I invoke using ${__P(threads,)} syntax and when running the non-GUI load test I pass those with -J to the command line (f.ex. jmeter -Jthreads=50 ...)
I didn't pass the loop parameter since I figured it would just default to 1 (and that is also the impression I get when looking at the logs where I see all thread started ... entries) - turns out for some reason it will log, but won't execute anything actually till I pass a value for that loop.
So if you run a test plan and notice it only simulates doing something but you get no results in the target log file -> confirm you're setting ALL variables used for thread groups including those you suspect to default
How to get the throughput of the samples while running jmeter in non-GUI mode?
In cmd only Avg,Min,Max,Err,Time elapsed is displayed?
Actually you have the throughput when you run your JMeter test in command-line non-GUI mode:
You can get a little bit more information if you run your JMeter test using Taurus tool as the wrapper:
or much more information if you run Taurus with -report command-line argument, it will kick off your default browser and bring up real-time results in a fancy web interface:
Check out Navigating your First Steps Using Taurus article for more details if needed
And last but not the least you can add a Backend Listener and point it to your InfluxDB installation, once done you will be able to use Grafana to view current test execution results in the real time:
by default if you're running your JMX file using cmd you will throughput in the cmd itself or if you want to see some more information you can use Taurus tool as well check this for more https://jmeter.apache.org/usermanual/realtime-results.html
I created JMeter Test and under first "HTTP Request" I created a Beanshell listner script which works fine when using GUI but 8 out of 10 times the script totally get ignored in non-GUI mode.
I am also running these test in Gitlab CI using Docker Image "justb4/jmeter:latest" and Beanshell script also get ignored there. I don't know whats wrong there it is working fine with GUI
There is no such thing as "get ignored" in JMeter world, it either passes or fails, in case of failure you should see the relevant message(s) in the jmeter.log file
Also be aware that you should not be using Beanshell at all, starting from JMeter 3.1 you should be using JSR223 Listener and Groovy language for scripting, one of Beanshell's disadvantages is that it's being interpreted each time while Groovy scripts can be compiled and cached providing the most optimal performance. See Apache Groovy - Why and How You Should Use It article for more details.
Also be informed that we cannot efficiently help without seeing your code and the aforementioned jmeter.log file.
During Distributed testing with Jmeter 3.3 in non gui mode i'm getting error as, how can I fix this :
I'm using same version of JMeter and JDK on Master as well as Slave machines.
The JVM should have exited but did not.
The following non-daemon threads are still running (DestroyJavaVM is OK):
Thread[main,5,main],
stackTrace:java.net.SocketInputStream#socketRead0
java.net.SocketInputStream#socketRead
java.net.SocketInputStream#read
java.net.SocketInputStream#read
java.io.BufferedInputStream#fill
java.io.BufferedInputStream#read
java.io.DataInputStream#readByte
sun.rmi.transport.StreamRemoteCall#executeCall
sun.rmi.server.UnicastRef#invoke
java.rmi.server.RemoteObjectInvocationHandler#invokeRemoteMethod
java.rmi.server.RemoteObjectInvocationHandler#invoke
com.sun.proxy.$Proxy19#rrunTest
org.apache.jmeter.engine.ClientJMeterEngine#runTest at line:149
org.apache.jmeter.engine.DistributedRunner#start at line:132
org.apache.jmeter.engine.DistributedRunner#start at line:149
org.apache.jmeter.JMeter#runNonGui at line:1005
org.apache.jmeter.JMeter#startNonGui at line:910
org.apache.jmeter.JMeter#start at line:538
sun.reflect.NativeMethodAccessorImpl#invoke0
sun.reflect.NativeMethodAccessorImpl#invoke
sun.reflect.DelegatingMethodAccessorImpl#invoke
java.lang.reflect.Method#invoke
org.apache.jmeter.NewDriver#main at line:248
I strongly recommend using this jmeter property:
jmeterengine.force.system.exit=true
documented here. These Chinese language web pages link link tipped me off.
You can add -Jjmeterengine.force.system.exit=true on the command line when launching JMeter, or add jmeterengine.force.system.exit=true to JMETER_HOME/bin/jmeter.properties.
How I Confirmed This Fix
With JMeter 5.1 and java version "1.8.0_231" on MS-Win10, we're using a customized version of this JMeter InfluxDB backend Listener.
After my 60 second test run from the command line (jmeter.bat -n -t plan.jtl), the command line hung after displaying this output (very similar to op):
Tidying up ... # Wed Jan 29 14:41:04 CST 2020 (1580330464874)
... end of run
The JVM should have exited but did not.
The following non-daemon threads are still running (DestroyJavaVM is OK):
Thread[DestroyJavaVM,5,main], stackTrace:
Thread[pool-2-thread-3,5,main], stackTrace:sun.misc.Unsafe#park
java.util.concurrent.locks.LockSupport#parkNanos
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#awaitNanos
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ThreadPoolExecutor#getTask
java.util.concurrent.ThreadPoolExecutor#runWorker
java.util.concurrent.ThreadPoolExecutor$Worker#run
java.lang.Thread#run
Thread[pool-2-thread-4,5,main], stackTrace:sun.misc.Unsafe#park
java.util.concurrent.locks.LockSupport#parkNanos
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#awaitNanos
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ThreadPoolExecutor#getTask
java.util.concurrent.ThreadPoolExecutor#runWorker
java.util.concurrent.ThreadPoolExecutor$Worker#run
java.lang.Thread#run
Thread[pool-2-thread-1,5,main], stackTrace:sun.misc.Unsafe#park
java.util.concurrent.locks.LockSupport#parkNanos
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#awaitNanos
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue#take
java.util.concurrent.ThreadPoolExecutor#getTask
java.util.concurrent.ThreadPoolExecutor#runWorker
java.util.concurrent.ThreadPoolExecutor$Worker#run
java.lang.Thread#run
After modifying my command line as follows, jmeter.bat cleanly exited instead of hanging and all the ugly stack trace went away too:
jmeter.bat -n -Jjmeterengine.force.system.exit=true -t plan.jtl
To confirm that the problem was caused by our customized JMeter InfluxDB backend Listener, I removed it from the .jmx and I also removed the jmeterengine.force.system.exit=true. No hang, no ugly stacktrace (I actually love stacktraces).
I have not taken the next step to discover whether the problem is with the official JMeter InfluxDB backend Listener or with our customized variant, which is not (and will never be) available publicly.
Should mention one gap in this story. I feel this test conclusively points to our customized backend listener (or jmeter's). However, its odd that none of the threads in the above thread dump seem to belong to the backend listener. So I applaud that JMeter did the right thing by dumping the stack trace -- few other apps go to the extent of auto-dumping when appropriate for troubleshooting. But in this case, perhaps that jmeter auto-dump code needs to be enhanced, because it did not point to the culprit backend listener code. Anyone over there at Apache listening in on this?
Good luck.
Most probably your JMeter engine(s) is(are) overloaded therefore cannot gracefully shut down running threads when you request them to do so.
Make sure you follow JMeter Best Practices
The very first "best practice" states Always use latest version of JMeter so consider migrating to JMeter 5.0 or whatever latest version is available at JMeter Downloads page
Make sure your JMeter instances have enough headroom to operate in terms of CPU, RAM and so on. You can use JMeter PerfMon Plugin for this if you don't have other monitoring software in place/in mind.
Take a thread dump and examine it - this way you will know where exactly your test is stuck
Introduce reasonable timeout values in HTTP Request Defaults so in case when server fails to respond JMeter wouldn't wait infinitely but rather fail with an error
And finally (however I wouldn't recommend this) you can suppress this check by adding the next line to user.properties file:
jmeter.exit.check.pause=-1
if you go for this keep in mind that you may run into a situation when JMeter slaves will still be trying to execute something even after your test ends so you will need to kill and restart the processes manually or using a script.
I'm having problem with jmeter while running the test plan. Suddenly my Jmeter starts hanging and appears as a black screen in GUI mode. I was running recording controller with multiple thread groups (4 thread groups). Each thread group with 25 users.
I'm using Jmeter 2.11 (current version). I'm not sure whether it is due to overload or some other reason.
Regards
Nayasoft
Don't ever use GUI mode for load test. Run JMeter in command-line non-GUI mode as follows
jmeter -n -t /path/to/your/testplan.jmx -l /path/to/testresults.jtl
Also if you have any listeners in your test plan - disable or remove them as well. After test execution you should be able to open testresults.jtl file with the listener of your choice and analyze results, but don't use them during load test.
Make sure that you following Performance Checklist and other recommendations from JMeter Performance and Tuning Tips guide
You have run out of JMeter/JVM memory. You can increase in with environment variables, command line options when you start jmeter, or change some values in jmeter.properties
This page describes how to start jmeter with more memory.
http://jmeter.apache.org/usermanual/get-started.html
One easy way is to set the environment variable before running jmeter:
set JVM_ARGS="-Xms1024m -Xmx1024m"
This will allow your tests to run longer before running out of memory, but if you store results in memory (for instance using View Results Tree listener), you will still run out eventually. For long running tests, or accurate measurement of short running tests, it is better to run in non-GUI mode, and save results to file, instead of memory.
Graphs can still be generated after the run from the saved results using jmeter utilities.