-
-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
testJps taking a considerable time on some platforms #2058
Comments
Please compare these to the runs at ci.eclipse.org/openj9. If the execution times are approximately the same then they are working as designed (or you can raise the issue at openj9 if you feel there is a better way to write the test). |
https://ci.eclipse.org/openj9/view/Test_Functional_Nightly/job/Test_openjdk11_j9_extended.functional_s390x_linux_Nightly_testList_0/169/testReport/org.openj9.test.attachAPI/ - 1.5 hrs, with TestJps taking 10sec. Perhaps start by comparing the machines and why TestJps takes 1hr 40min on test-marist-ubuntu1604-s390x-2X and 10sec on rh7-390-3. |
Thanks Shelley, yes, considerable difference in timing! i'll have a look at what the test is doing |
Running some debug tests on machine: https://ci.adoptopenjdk.net/computer/test-marist-ubuntu1604-s390x-1/
|
I have killed all these rogue processes and rerun my JpsTest Grinder on that machine: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4713/ |
I've adjusted the SXA-processCheck job to allow it to hit processes with |
This is very good to hear 👍 |
Previously (and still now by default) it would run this line and not issue a hard kill if a normal one didn't work:
My view is that if a job gets into a state where it won't respond to a normal kill signal then that's a bit of a serious error case and we should be trying to look into where it's locked up like that and see if it's a JVM issue that we can resolve - the processCheck job was only really intended to be a mitigation until we tried to stop those situations occurring. Happy to accept willing volunteers to look into any locked-up processes obvs ;-) |
Yep, agree @sxa, as briefly mentioned in call today, the idea would be to attempt to figure out which tests are culprits. Talked with @renfeiw and there is a branch with some other environment checks being worked on by a part-time student. I think we can/should proceed with adding Will's fix to maketest.sh in the interim, while we wait for the other environment checks work to land, then we can move it from maketest to TKG (once the landing spot is ready). |
Having run the overnight SXA process cleanup, the jpsTest now runs in 14 seconds |
The extended.functional testJps set of 6 tests is taking a considerable amount of time on some platforms,eg:
jdk11 J9 aarch64 : 49 mins : https://ci.adoptopenjdk.net/view/Test_functional/job/Test_openjdk11_j9_extended.functional_aarch64_linux/36/testReport/org.openj9.test.attachAPI/TestJps/
jdk11 J9 AIX : 51mins : https://ci.adoptopenjdk.net/view/Test_functional/job/Test_openjdk11_j9_extended.functional_ppc64_aix/8/testReport/org.openj9.test.attachAPI/TestJps/
jdk11 J9 s390x : 1hr40mins : https://ci.adoptopenjdk.net/view/Test_functional/job/Test_openjdk11_j9_extended.functional_s390x_linux/6/testReport/org.openj9.test.attachAPI/TestJps/
jdk8 J9 s390x : 1hr40mins : https://ci.adoptopenjdk.net/view/Test_functional/job/Test_openjdk8_j9_extended.functional_s390x_linux/23/testReport/org.openj9.test.attachAPI/TestJps/
The text was updated successfully, but these errors were encountered: