Sag*_*shi 5 distributed jvm jmeter load-testing performance-testing
在非 gui 模式下使用 Jmeter 3.3 进行分布式测试期间,我收到错误,我该如何解决这个问题:
我在 Master 和 Slave 机器上使用相同版本的 JMeter 和 JDK。
JVM 应该已经退出但没有退出。以下非守护进程线程仍在运行(DestroyJavaVM 是可以的): 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
Run Code Online (Sandbox Code Playgroud)
我强烈建议使用这个 jmeter 属性:
jmeterengine.force.system.exit=true
Run Code Online (Sandbox Code Playgroud)
您可以-Jjmeterengine.force.system.exit=true在启动 JMeter 时在命令行中添加,或添加jmeterengine.force.system.exit=true到 JMETER_HOME/bin/jmeter.properties。
我如何确认此修复
在 MS-Win10 上使用 JMeter 5.1 和 java 版本“1.8.0_231”,我们使用的是这个JMeter InfluxDB 后端 Listener的定制版本。在我从命令行 (jmeter.bat -n -t plan.jtl) 运行 60 秒后,命令行在显示此输出后挂起(与 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
Run Code Online (Sandbox Code Playgroud)
如下修改我的命令行后,jmeter.bat 干净地退出而不是挂起,所有丑陋的堆栈跟踪也消失了:
jmeter.bat -n -Jjmeterengine.force.system.exit=true -t plan.jtl
Run Code Online (Sandbox Code Playgroud)
为了确认问题是由我们定制的JMeter InfluxDB 后端 Listener引起的,我从 .jmx 中删除了它,我还删除了 jmeterengine.force.system.exit=true。没有挂起,没有丑陋的堆栈跟踪(我实际上喜欢堆栈跟踪)。
我还没有采取下一步措施来发现问题是出在官方的JMeter InfluxDB 后端侦听器上,还是出在我们定制的变体上,后者尚未(也永远不会)公开提供。
应该提到这个故事中的一个缺口。我觉得这个测试最终指向我们定制的后端侦听器(或 jmeter 的)。然而,奇怪的是,上述线程转储中的线程似乎都不属于后端侦听器。所以我赞赏 JMeter 通过转储堆栈跟踪做了正确的事情——很少有其他应用程序在适合故障排除时达到自动转储的程度。但在这种情况下,也许那个 jmeter 自动转储代码需要增强,因为它没有指向罪魁祸首的后端侦听器代码。Apache 那边有人在听吗?
祝你好运。
您的 JMeter 引擎很可能已超载,因此当您请求它们关闭正在运行的线程时,它们无法正常关闭。
在HTTP 请求默认值中引入合理的超时值,这样当服务器无法响应时,JMeter 不会无限等待,而是会失败并出现错误
最后(但是我不推荐这样做)您可以通过将下一行添加到user.properties文件来抑制此检查:
jmeter.exit.check.pause=-1
Run Code Online (Sandbox Code Playgroud)
如果您这样做,请记住,您可能会遇到这样的情况:即使测试结束后,JMeter 从属设备仍会尝试执行某些操作,因此您需要手动或使用脚本终止并重新启动进程。