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.
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
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
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
Following parameters should be set for OBIEE Presentation Server only during load testing.
OBIPS\instanceconfig.xml
save and exit file Restart OBIEE processes using OBIEE EM console.
<ServerInstance>
[...]
<Cursors>
<NewCursorWaitSeconds>36000</NewCursorWaitSeconds>
<OldCursorWaitSeconds>36000</OldCursorWaitSeconds>
</Cursors>
[...]
</ServerInstance>
You do know that this represents a value of 10 hours, correct? You are willing to lock resources for that length of time? This is counterintuitive for optimal application performance as you would seek to recover resources as fast as possible to support more sessions versus locking a resource for an extended period of time.
I refer to the following performance "compass rose" as a guiding item (independent of tool)
If you need to amend the file on a remote server you can do this either via OS Process Sampler or via SSH Command Sampler. The first one is a part of JMeter installation, the second one you can install using JMeter Plugins Manager
See How to Run External Commands and Programs Locally and Remotely from JMeter for more information, example configuration and sample commands.
I have three slaves (jmeter-servers) running on EC2 instances, and in one case – (1) JMeter GUI on a local laptop, on another – same test plan (2) running from a command line on yet another EC2 instance.
In case of GUI I can see all the aggregated numbers for Throughput, 99%, etc. in – well, GUI. I'm creating a jtl file with Aggregate Report listener.
From watching Datadog charts monitoring the application server parameters (CPU usage, memory, etc.) I see that in case of a command line and everything on EC2 load is more than twice higher than when my local laptop is communicating with the jmeter-servers, meaning probably that the network becomes a bottleneck. So I want to run everything on EC2.
But then – how do I get access to the same aggregated numbers when I'm running from the command line when all four machines are EC2 instances? The huge jtl file contains records for each transaction, not the aggregated one line of the entire run result.
On an attempt to download that jtl from EC2 and open it in GUI on a local laptop it generates some error instead of showing aggregated data.
Am I using a wrong listener to get to the summary data? (Tried Summary Report – it creates even larger jtl file, not the one line I'm looking for.)
Problem in this case is not running scripts via JMeter GUI. Instead it is related to network.
I had a similar distributed setup in EC2-environment and I successfully executed heavy load tests in GUI mode. In my case, all my JMeter (master/slaves) were running on EC2 instances (windows environment). So, I will recommend you to setup your JMeter (Master) on EC2 and run scripts via GUI mode.
If you still want to run in command line mode then you simply need to pass command to create jtl file while the script runs on command line. Later on you can use this JTL to generate any JMeter report as per requirement. For more details check..
Jmeter - Run .jmx file through command line and get the summary report in a excel
jmeter -n -t /path/to/your/test.jmx -l /path/to/results/file.jtl
Please refer to Dmitri answer in following question to reduce JTL size.
How can we control size of JTL file while running test from Non GUI Mode