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?
Related
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.
Apologies in advance. I know this is a basic question.
I am new to server administration. I am administering a server where the users do Java development.
They have a Java-based application and do development in Eclipse. Eclipse is 32-bit. The OS is 64-bit.
I recently updated the JDK and JRE on the server. I have both the 64-bit and 32-bit of each installed.
Eclipse ran into an error where it couldn't start after I had updated to the new JRE and JDK. So I took some advice online and updated the -vm path in the Eclipse .INI file to point to the new 32-bit JRE path. It now works.
I have two main questions:
Will updating the JRE and JDK EVER cause an issue with development, or as long as they can open up Eclipse and use at least one version of the JRE or JDK, they will be fine? I guess my fear is that they are going to develop in a certain version and the next version will cause issues down the line.
They develop in 32-bit Eclipse (not sure why they chose 32-bit) but their application runs with 64-bit Java (that is where the path points to for that installation). If something is developed in 32-bit Eclipse can it run with 64-bit Java? Side question: is there a certain advantage with developing with 32-bit Eclipse on a 64-bit system or is it personal choice?
Thanks a lot and cheers!
I guess my fear is that they are going to develop in a certain version and the next version will cause issues down the line.
Java 6 and 7 are end of life; Java 8 code should still be run when Java 9+ rolls out. I've not been aware of any backwards compatibility issues in recent years, it's only forward compatibility that doesn't work (running Java 8 compiled libraries with JRE 7).
They develop in 32-bit Eclipse (not sure why they chose 32-bit) but their application runs with 64-bit Java
The IDE and code run in separate processes. There's no harm in using the 64bit JDK with 32bit editor.
Eclipse 32 bits running on 64 bits JVM
Should I use Eclipse 32bits or 64bits on my new machine?
Will updating the JRE and JDK EVER cause an issue with development...
I believe it technically could render what you developed "obsolete" if you're initially using one JDK with some specs and change for another one with specs that are not "compatible" with what you built so far. By specs, I mean the libraries, tools, etc that the JDK contains. But I would say it would be unlikely that such problems occur. It personally never happened to me. I'd like to have someone with more knowledge give more details though and validate what I'm saying or correct me if I'm wrong.
If something is developed in 32-bit Eclipse can it run with 64-bit
Java?
To my knowledge, there are not related things. In my mind, Eclipse is just your IDE and it allows you to build/compile code using specific JDK (32 or 64 bits). As a matter of fact, you don't even need eclipse to build code but you definitely need a JDK: it's the JDK that give you the tools to compile code that "targets" a specific JRE/JVM and Eclipse is using the tools your JDK provide.
So yes, you can use eclipse 32 bits to build code for a 64 bits JRE.
My Eclipse (or, more specific, Spring Tool Suite) version is:
Version: 3.6.3.RELEASE
Build Id: 201411281415
Platform: Eclipse Luna SR1 (4.4.1)
It worked fine, until recently, when I started getting the following error after opening Eclipse:
Error: Could not create the Java Virtual Machine
Error: A fatal exception occured. Program will exit.
My start options include -vm <path to javaw> -vmargs -Xmx1024m -XX:MaxPermSize=256m, I am using jdk1.7.0_79, the 32 bit version, on a 64bit Windows.
I discovered, when setting -Xmx to 768m, Eclipse will start most of the time. I also noticed that starting eclipse began to fail when I installed the MySQL service; if I deactivate it, the Task Manager shows me I have roughly 4gb of 16gb of RAM consumed; with MySQL running, that value increases to 5gb.
What is the reason, when there are 5gb consumed and roughly 11gb of RAM left, that no JDK can be created, and is there a known workaround?
It is likely because of lack of virtual address space. Remember that 32-bit processes have only 2GB of virtual space, which is needed for:
application code
DLLs, both application DLLs and shared DLLs like hooks
java off-heap needs: code caches, buffers, etc.
java heap itself
So, physical RAM is unrelated.
What likely happened?
Eclipse grew heavier so JVM needs more off-heap to function
What you can do?
Uninstall unneeded plugins, shut down your antivirus or other software that could intervene with Eclipse, use 64bit java. 64bit apps are faster on modern processors + 64-bit java uses compressedOps so it could make sense.
In the past i had simlar issues, but no solution. I reached the limit with -Xmx1500m.
See also Maximum Java heap size of a 32-bit JVM on a 64-bit OS.
Is using the 64 bit Version of the JDK no option?
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.
We've been using the 32bit linux version of the JavaServiceWrapper for quite a while now and it's working perfectly. We are now considering also using it on 64bit linux systems. There are downloads for 64bit binaries on the website, but looking into Makefile for the 64bit version I found the following comment, though:
# This makefile is in progess. It builds, but the resulting libwrapper.so does not yet work.
# If you know how to fix it then please help out.
Can anyone confirm, that this comment is just outdated and the resulting wrapper will work without flaws?
I've had it running in production on 64-bit red hat without any trouble for the last year or so.
From http://wrapper.tanukisoftware.org/doc/english/introduction.html :
Binary distributions are provided for
the following list of platforms and
are available on the download page.
Only OS versions which are known to
work have been listed.
(snip...)
linux - Linux kernels; 2.2.x 2.4.x, 2.6.x. Known to work with Debian and Red Hat, but should work with any
distribution. Currently supported on
both 32 and 64-bit x86, and 64-bit ppc
systems.
Take a look at http://yajsw.sourceforge.net/.
It's free and rather compatible reimplementation of TanukiSoftware Java Service Wrapper featuring free 64-bit support.