I am running a Java application on Java 17.0.0 from Azul - Zulu17.28+13-CA, with bundled JavaFX. Everything is working fine, except that the CPU usage simply says "unknown". I've seen messages before about "unavailable with this JVM" or something similar to that, when I ran VisualVM on older JDKs, but this is different.
VisualVM itself is running on JDK 19.0.1.
About box reports: Azul 19.0.1; OpenJDK 64-Bit Server VM (19.0.1+10, mixed mode, sharing)
The same version of VisualVM running on JDK 19.0.1 on a different system is able to get CPU usage for an application running on Oracle JDK 8u60 (ancient, I know).
Does the Azul JVM that I am trying to monitor not support something to do with CPU monitoring that Oracle Java does?
As it turns out, the JRE that the application was running on was an image made with jlink that lacked the jdk.management module. When that module was added to the JRE, the CPU usage was reported properly.
More details at GH-479.
Related
I have a Centos7 server and I want to monitor the JVM in order to identify performance issue but I have only JRE installed on the prod environment as follows:
Based on the research I saw there were some tool available such as Java Mission Control but it is only available with JDK but I have JRE installed. Any idea what open source tool I can use to monitor the jvm on centos with only JRE installed?
jattach gives you access to a few powerful tools, namely jcmd which you can then use to run various diagnostics commands against the java app.
Works with plain JRE - check https://github.com/apangin/jattach
See also https://docs.oracle.com/en/java/javase/17/docs/specs/man/jcmd.html
Since I switched to OpenJDK 1.8 (linux debian, openjdk version "1.8.0_242"), I encountered a lot of issue with filesystem usage.
The CPU has really high usage peaks, over 150%, by only browsing files in applications like netbeans (8 to 11) and every other java apps that reads directories contents, resulting in a system slowdown after a bit.
The problem seems to be not present in the Oracle JRE 1.8 bundled with old netbeans 8.2 (java version "1.8.0_101").
I attached a screenshot.
Netbeans 11 cpu usage
Has anyone else experienced this?
As the title says, I would like to install IBM java (from IBM's Java SDK downloads) on WSL. However, the "InstallAnywhere root not required" file creates a folder and so on, but just executing a simple <path>/java -version command takes several minutes.
Is there an inherent incompatibility or another requirement that creates this problem?
Some background information:
Windows 10 Enterprise 1703 64 bit
There are no other Java versions installed (in WSL)
WSL reports (uname -a) Linux computername 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
The Java version reported (after a long wait) is:
` java version "1.7.0"
Java(TM) SE Runtime Environment (build pxa6470sr10fp15-20171116_01(SR10 FP15))
IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 Compressed References
20171011_366933 (JIT enabled, AOT enabled)
J9VM - R26_Java726_SR10_20171011_1726_B366933
JIT - r11_20171011_366933
GC - R26_Java726_SR10_20171011_1726_B366933_CMPRSS
J9CL - 20171011_366933)
JCL - 20171109_01 based on Oracle jdk7u161-b13
Thanks!
UPDATE - January 2018
Microsoft has made significant improvements to the underlying technology and memory management in WSL, and the latest versions of Windows 10 Insiders work well with the JVM. It is not as fast as a native Linux machine, but it is now possible to work in the WSL environment without suffering form major delays for simple command execution. The answer is now yes, but you must have Windows 10 build 17074 or better in order to have decent performance.
--- ORIGINAL ANSWER - Dec, 2017 ---
After some research, I found out that the answer is both Yes and No:
Yes, because the JDK installs correctly and functions as expected (other than speed) in the platform without any special modifications or configuration.
No, because due to the architecture of the WSL, certain memory mapping functions work different in WSL than in a fully native Linux environment. Users have reported very slow performance using Haskell, and it looks like Java suffers from the same problem too. There have been significant improvements in Windows 10 releases since the summer of 2017, but it is still slow compared to a native system.
Microsoft is still actively working on this issue, though, and the "No" part of this answer may be fixed in the near future.
as the headline mentioned: is it possible to connect VisualVM to an remote application running on JRE instead of JDK ?
And yes, the VisualVM itself runs on JDK !
Kind regards
Dominik
VisualVM connects to a running Java Virtual Machine (JVM).
And this JVM is contained both in the JDK and the JRE.
In fact, the JDK is a JRE with additional tools and items to allow creating Java programs. If you only want to run them, you only need a JDK.
So yes, you can connect to a JRE-only install.
Are there known Tomcat 6.0 and JDK 1.7.0_02 issues?
I know this is a hard question to answer, if the answer is no. But I need to ask just in case the answer is yes. Also I will accept any solutions to the issues below as answers. Please just share whatever issues you have had, and I will update this question if need be.
Issues:
Some issues I have run into since upgrading from JDK 1.7.0 to 1.7.0_02 (which I did to avoid the Eclipse's help menus from crashing, due to a Java 1.7.0 bug.):
Tomcat server takes much longer to start, I need a 120 second timeout to handle it.
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197) error, which disappeared the next day and then reappeared the third day, with no changes other than reloading Eclipse.
Tomcat server takes much longer to shut down. I need a 60 second timeout to handle it, from 15 second default.
Eclipse itself appears to crawl to a halt (figuratively speaking) upon building the workspace and validating the project at hand. Everything within Eclipse appears to take longer, even opening an unopened file.
Everything seems suspicious.
P.S. JDK 1.7.0_02 is also known as 1.7.0u2, Java SE 7u2, Java SE 7 Update 2, etc.
Versions:
JDK = Oracle, 64-bit, downloaded from http://www.oracle.com/technetwork/java/javase/downloads/index.html. Exact file downloaded and installed was jdk-7u2-windows-x64.exe.
Tomcat = Tomcat 6.0.33, downloaded separately from Eclipse
Eclipse = Eclipse Java EE IDE for Web Developers., Version: Indigo Release, Eclipse Platform, Version: 3.7.0.v20110530-9gF7UHNFFt4cwE-pkZDJ7oz-mj4OSEIlu9SEv0f, Build id: I20110613-1736.
64-bit Windows 7 machine, 8GB RAM, Intel Core i7-2600 CPU # 3.4GHz (4 cores)
Eclipse, Tomcat, Apache HTTP Server, are all on the same (development) computer.
EDIT: Added system specs above.
When running 64 bits Java with default options (references compaction is off by default), it requires almost twice the amount of memory than with 32 bits.
For Eclipse, open the eclipse.ini file and double/increase a lot the -Xmx option.
Of course, your physical memory may not be enough when running some JVMs.
So I recommend you to test the -XX:+UseCompressedOops HotSpot option with 64 bits JVM and monitor memory usage thanks to jconsole for instance. You can also read details about that recent option. That option
For Tomcat, create the file bin/setenv.bat with content:
set JAVA_OPTS="-Xmx1024M -XX:+UseCompressedOops"
Well, perhaps it's all about the new JVM released in that update. It alledgedly improves performance but... well, who knows. JDT on Tomcat6 interacts with JDK 1.7 so unexpected things could happen.
Other than that, there're few things to check.