Open mattlavinder opened 2 years ago
Just to add to this, I just used start
for the first time and it is very slow as well.
Oof. No, this amount of time is not expected. This is especially true for non-operative commands like sc list
. All sc list
is doing is reading the configuration files.
For comparison, on my development system, sc list group:all
takes under 2s. Even a more complex operation, like sc check all
takes less than 4 seconds.
One might ask if your system is underpowered, but even then it's hard to explain this magnitude of difference!
Maybe there's something wrong with Java itself (environmental or otherwise). How long does an invocation of /QOpenSys/pkgs/lib/jvm/openjdk-11/bin/java -version
take?
I have to agree with @ThePrez sc list group:all returns very quickly
That would appear to be the problem. It is taking Java a LONG time just to return a version.
It is slow via SSH, but I just tried it from QP2TERM and it was fast.
I may have an idea of what the issue is, but I will have to wait until tomorrow to verify I have it resolved. Can't just shut down SSH in the middle of the day, unfortunately.
My idea did not work. It is still slow. Do either of you have any ideas as to why this would be so slow via SSH? Google is not being particularly helpful on this one.
Are you going through a VPN for your SSH? Are you connecting via IP or a DNS name? Are the DNS servers reachable? Just general networking problem handling I would start with.
HTH.
Still grasping at straws, a couple more questions:
/QOpenSys/pkgs/lib/jvm/openjdk-11/bin/java -Djava.awt.headless=true -version
run any faster?@mattlavinder , my curiosity remains piqued regarding this issue. Have you gotten any findings since last update?
Also, curious if /QOpenSys/QIBM/ProdData/JavaVM/jdk80/64bit/bin/java -version
is equally slow.
I did encounter a system where Java startups were incredibly slow (still not several minutes!!) and it was somehow related to an egregious amount of temporary storage in use by the system. Perhaps related (?)
i have the same problem , java 11 is very slow !! ( on SSH terminal , but is slow on QSH too )
#!/QOpenSys/pkgs/bin/bash
start=$(date +%s)
/QOpenSys/QIBM/ProdData/JavaVM/jdk80/64bit/bin/java -version
end=$(date +%s)
echo "Elapsed Time java8 : $(($end-$start)) seconds"
start=$(date +%s)
/QOpenSys/pkgs/lib/jvm/openjdk-11/bin/java -version
end=$(date +%s)
echo "Elapsed Time java11 : $(($end-$start)) seconds"
qsecofr@A4:~# ./test.sh
java version "1.8.0_341"
Java(TM) SE Runtime Environment (build 8.0.7.15 - pap6480sr7fp15-20220728_01(SR7 FP15))
IBM J9 VM (build 2.9, JRE 1.8.0 OS/400 ppc64-64-Bit Compressed References 20220713_32322 (JIT enabled, AOT enabled)
OpenJ9 - 95866f0
OMR - a79eb1a
IBM - 7175f82)
JCL - 20220727_01 based on Oracle jdk8u341-b10
Elapsed Time java8 : 1 seconds
openjdk version "11.0.14-ea" 2022-01-18
OpenJDK Runtime Environment (build 11.0.14-ea+9)
Eclipse OpenJ9 VM (build openj9-0.30.0, JRE 11 OS400 ppc64-64-Bit Compressed References 20220209_53 (JIT enabled, AOT enabled)
OpenJ9 - 9dccbe0
OMR - dac962a
JCL - 01f8665 based on jdk-11.0.14+9)
Elapsed Time java11 : 41 seconds
@openmax thanks for reporting. I'd really like to get to the bottom of this. Do you have JV1 option 19 installed? If so, does it also exhibit this slowness?
Also, do the values compare badly when -Xmx
is specified for both invocations? For instance:
#!/QOpenSys/pkgs/bin/bash
start=$(date +%s)
/QOpenSys/QIBM/ProdData/JavaVM/jdk80/64bit/bin/java -Xmx80m -version
end=$(date +%s)
echo "Elapsed Time java8 : $(($end-$start)) seconds"
start=$(date +%s)
/QOpenSys/pkgs/lib/jvm/openjdk-11/bin/java -Xmx80m -version
end=$(date +%s)
echo "Elapsed Time java11 : $(($end-$start)) seconds"
oh yea -Xmx80m solve the slowness ..
java version "1.8.0_341"
Java(TM) SE Runtime Environment (build 8.0.7.15 - pap6480sr7fp15-20220728_01(SR7 FP15))
IBM J9 VM (build 2.9, JRE 1.8.0 OS/400 ppc64-64-Bit Compressed References 20220713_32322 (JIT enabled, AOT enabled)
OpenJ9 - 95866f0
OMR - a79eb1a
IBM - 7175f82)
JCL - 20220727_01 based on Oracle jdk8u341-b10
Elapsed Time java8 : 1 seconds
openjdk version "11.0.14-ea" 2022-01-18
OpenJDK Runtime Environment (build 11.0.14-ea+9)
Eclipse OpenJ9 VM (build openj9-0.30.0, JRE 11 OS400 ppc64-64-Bit Compressed References 20220209_53 (JIT enabled, AOT enabled)
OpenJ9 - 9dccbe0
OMR - dac962a
JCL - 01f8665 based on jdk-11.0.14+9)
Elapsed Time java11 : 0 seconds
need time to install jv1 19 and ptf , when ready i try ..
without -Xmx80m java8 e 11 of 5770jv1 good , java11 rpm pase no good :
java version "1.8.0_341"
Java(TM) SE Runtime Environment (build 8.0.7.15 - pap6480sr7fp15-20220728_01(SR7 FP15))
IBM J9 VM (build 2.9, JRE 1.8.0 OS/400 ppc64-64-Bit Compressed References 20220713_32322 (JIT enabled, AOT enabled)
OpenJ9 - 95866f0
OMR - a79eb1a
IBM - 7175f82)
JCL - 20220727_01 based on Oracle jdk8u341-b10
Elapsed Time java8 : 2 seconds
java version "11.0.16.1" 2022-08-12
IBM Semeru Runtime Certified Edition (build 11.0.16.1+1)
Eclipse OpenJ9 VM (build openj9-0.33.1, JRE 11 OS/400 ppc64-64-Bit Compressed References 20220908_000000 (JIT enabled, AOT enabled)
OpenJ9 - 1d9d168
OMR - b58aa27
JCL - 25404e5 based on jdk-11.0.16.1+1)
Elapsed Time java11 : 3 seconds
openjdk version "11.0.14-ea" 2022-01-18
OpenJDK Runtime Environment (build 11.0.14-ea+9)
Eclipse OpenJ9 VM (build openj9-0.30.0, JRE 11 OS400 ppc64-64-Bit Compressed References 20220209_53 (JIT enabled, AOT enabled)
OpenJ9 - 9dccbe0
OMR - dac962a
JCL - 01f8665 based on jdk-11.0.14+9)
Elapsed Time java11 : 43 seconds
as workaround i use : export OPENJ9_JAVA_OPTIONS="-Xmx3584m" in my /home/"user"/.bashrc
3584 is the max value after that it slow down .. ( 3584 / 1024 = 3.5 )
it look like a 32bit limit ?
@openmax I think you're really onto something. Slow Java startups are somehow related to max heap usage. I'll raise the issue with the IBM Java team in charge of OpenJDK.
Regardless, changing sc
to always run with an -Xmx2G
is probably a good change either way.
Honestly, -Xmx1G
is probably more than enough
I've been running a few commands and they all seem REALLY slow. Is this to be expected, or is there possibly something wrong with my configuration? It took several minutes for
sc list group:all
to complete.