In run.conf of JBoss AS there are few parameters which I am unable to figure out how they are used MAX_FD, PROFILER, JAVA_HOME, JAVA. Can somebody explain the use of these parameters. I agree I am new to JBoss and these are preliminary questions.
From this wiki entry
JAVA_HOME : The location of the JDK (java development kit)
JAVA_OPTS : Options passed the java command, e.g. -Xmx512M
JAVA : The name of the java binary (default java)
JBOSS_CLASSPATH : additional classpath entries, if this is set, its value will be prepended to the classpath at startup
MAX_FD : The maximum number of file descriptors used by JBoss (Unix only)
Actually Xms is for defining minimum memory size that is to be allocated for the deployed jboss Appplication and Xmx is maximum memory size.If any exception like "Out of Memory" we should increase this memory size for the application from this run.conf file.
That is increase the range of Xms - Xmx value
Related
When I run the program from PyDev/Eclipse, it runs out of memory and gives the following error:
java.lang.OutOfMemoryError: java.lang.OutOfMemoryError: GC overhead
limit exceeded
It goes away when I pass the -J-Xmx2048 limit from the command line. So clearly, this can be solved if PyDev can read these somehow.
In Eclipse, I tried setting this values in the run options (in eclipse) as program & vm arugments, but I get the same error. I also tried setting the JAVA_MEM option, but that doesn't help either.
Any ideas how I can instruct PyDev/Eclipse to read these arguments?
It turns out that the Run As -> Run Configurations -> Arguments -> Vm Arguments for Jython also expect Java arguments and not Jython ones :/
Setting the VM arguments to -Xmx2048 fixed the issue. The memory usage for java now peaks to 2G (earlier 1G) confirming the fix.
In my eclipse, while running a mapreduce program, it is throwing Out of memory exception
I tryied with changing the parameters in eclipse.ini (-Xms40m
-Xmx768m values to -Xms4000m
-Xmx7680m) but still getting the same error.
What would be the solution for this.
The eclipse.ini setting only sets the heap for Eclipse itself.
For a program you run from Eclipse look at the Run Configuration for the program and set the -Xmx value in the VM arguments.
I was trying to parse the 11GB heap dump using Eclipse MAT and I am getting the following error
An internal error occurred during: "Parsing heap dump"
I think the MAT is unable to parse such a huge heap dump. I read some posts and increase the VM configurations to more than 80% of the dump size. Following are my vm configurations
-vmargs -Xms8192m -Xmx10240m
and I am still not able to load the dump. I tried with ParseHeapDump.bat with no changes ...
Keep increasing Xmx till the JVM complains, then increase your swap file size, then increase Xmx again, etc.
At that stage it will take ages because it will be using disk as RAM.
I recently installed Eclipse MAT (Eclipse Memory Analyzer Version 1.9.1) on Mac OS Catalina (10.15.3). I needed to review a 4g heap dump. The default JVM heap size for MAT is 1024m.
I think the easiest way to increase the JVM's heap size is to use a shell window - go to the /Applications/mat.app/Contents/Eclipse/ folder. Then vi MemoryAnalyzer.ini and change -Xmx1024m to your required value, in my case I went with -Xmx10g.
To review the change, restart MAT and go to the help -> About Eclipse Memory Analyzer then click installation details, and look for the entry: eclipse.vmargs=-Xmx10g about 50 lines down.
This setup worked for me.
I also recently installed Eclipse MAT to analyze a 4.85GB heap dump file.
Eclipse Memory Analyzer Version: 1.11.0
MacOS Catalina: 10.15.7
Hardware Memory: 16GB
Heap dump file size: 4.85GB
Heap dump file type: PHD
Classes: 33.6k
Objects: 4.8m
Class Loader: 575
I changed the MemoryAnalyzer.ini to 14GB as follows:
-vmargs
-Xmx14g
I also confirmed the configuration as follows:
Help -> About Eclipse Memory Analyzer 1.11.0
Clicked on Installation Details
Clicked on Configuration tab
Looked for eclipse.vmargs=-Xmx14g.
It took some minutes to load this 4.85 heap dump file.
Note: I unsuccessfully tried Xmx setup with 2g, 4g, 8g, 10g, 12g - all failed with JVM out-of-memory in the Eclipse MAT tool.
On the Windows install of Eclipse Photon, I got around the problem by updating the memory parameters in the eclipse.ini file. This was directly under my c:\eclipse folder.
-Xms6g
-Xmx6g
I tried setting it to 4 gigs for a memory dump that was about 4.1GB and it failed. So, the rule of thumb is to set it to a higher value than the size of the memory dump.
My eclipse sometimes starts using 100 % of my CPU very spontaneously.
I can't figure out why it needs that much CPU usage. There is no background task like "building workspace" running.
After some time the CPU load drops to 0 and everything is normal.
I can't find any information related to the problem in workspace/.metadata/.log file.
Has anybody some tip how I can figure out which part of eclipse is using the CPU so heavily? Is there a way to get a thread dump of eclipse? The kill -3 on the eclipse process doesn't do anything.
Eclipse Version: Galileo JavaEE
Operating System: Linux 2.6.31
Sounds like garbage collection
You could try changing the settings in your eclipse.ini, maybe with a higher Xmx value
--launcher.XXMaxPermSize
256m
-vmargs
-Xms256m
-Xmx1024m
-XX:PermSize=64m
-Xss1M
-server
-XX:+DoEscapeAnalysis
-XX:+UseConcMarkSweepGC
You can use visualvm to profile eclipse, get a heap dump or a thread dump, see which threads are running, etc.
If anyone else is having this problem, I fixed it for myself.
Set the option "auto build project" to off. That should remove a lot of the CPU used by Eclipse.
For my installation, I noticed the heap status indicator (Enabled VIA Window>Preferences "Show heap status" under General) was displaying less max heap than allocated in eclipse.ini (the -Xmx setting). The status indicator was bouncing around indicating that garbage collection was struggling to keep memory low.
Increasing the initial/min heap size (the -Xms setting) seems to have caused Eclipse/Java to stop trying to manage memory as much.
Eclipse is loading and unloading information from memory whenever this is required. If you workspace is big and you work with multiple projects and also your eclipse is configured to use low ammount of memory this is normal. Someone suggested above to change the xmx and xms values so that your eclipse uses more memory (if you have available) I suggest u put the same value to both of them. For example -Xms4048m and -Xmx4048m (or more) in your eclipse.ini file. This way your system will attempt to make use of that space once you start your IDE and the Garbage Collector (GC) takes less time to process data.
For me, the solution was to give Eclipse fewer threads. From my really long answer here:
Solution: decrease the max number of threads Eclipse can use, down to 1/2 as many as your computer has. So, if your computer has 8 physical "cores" (actually: hyperthreads), then decrease the max number of threads that Eclipse can use to 4, or <= half of your number of cores for your system, as follows:
In $HOME/eclipse/cpp-2022-09/eclipse/eclipse.ini on Linux Ubuntu, or equivalent for your OS, make this change (reducing from 10 threads max, to 4, in my case):
Change from:
-Declipse.p2.max.threads=10
to:
-Declipse.p2.max.threads=4
Restart Eclipse.
Now, Eclipse can only take up to 4 of my 8 threads, and my system runs much better!
Read my long answer for more details and other changes I made to help: High CPU usage in Eclipse when idle
I cannot get JBoss Portal to start from Eclipse, though the AS alone starts fine, and the Portal starts correctly as well, when started from the command line as opposed to from within Eclipse. I'm running in Windows, with 3GB. Suggestions? Thank you.
I've spend hours to discover this, and almost gave up and started to use JBoss out of Eclipse.
In order to increase your JBoss vmargs when starting it from Eclipse you have to change JBoss launch configuration. If you change standalone.conf, nothing happens because Eclipse doesn't use it.
So, to change JBoss vmargs in Eclipse, you have to go to "Servers" tab, right click on your Jboss instance, and select "Open".
It will appear a new window. In the first section, you have a option: "Open launch configuration". When you click there, you'll see the textbox to change vmargs.
Hope this helps you!
There are different types of OutOfMemory errors:
java.lang.OutOfMemoryError: Java heap space
Increase the -Xms and -Xmx. I'd make sure they are set at least 256m and generally it's a good idea to set them to the same value.
java.lang.OutOfMemoryError: PermGen space
Add either -XX:+CMSPermGenSweepingEnabled or increase the PermGen size: -XX:PermSize=256m
java.lang.OutOfMemoryError: GC overhead limit exceeded
Add more heap, the garbage collector can't free enough memory with each cycle. Also try turning on GC logging.
java.lang.OutOfMemoryError: unable to create new native thread
Decrease your heap :) This means that you have too much memory allocated to the heap that the OS doesn't have enough memory to create threads..
Two last things, the above can be configured in jboss/bin/run.conf.
Also when starting JBoss see what -X parameters are being passed to the JVM, it prints this information by default, verify that it's what you expect it to be.
You need to increase the memory you're allocating to Java, in particular heap space and PermGen. This article is highly relevant. It mentions that this issue often occurs with Eclipse and JBoss (since both are fairly large), and provides a solution (adjusting the command-line flags).
What are you using for running portal from eclipse? Maybe Jboss tools can help you
http://www.jboss.org/tools
According to my experiments, all options of vmargs set in eclipse.ini, plays only once - when creating a new workspace. When you want to change the options in the existing workspace, use run/debug configuration as in https://stackoverflow.com/a/10814631/715269. vmargs in ini won't be read any more.
Be careful, you should set -XX:MaxPermSize=...M, not -XX:PermSize=..., the last sets minimal, starting PermSize.
ad. Jeremy. It is senseless to put mins and maxs to the same value. You deprive Eclipse of adaptability. -Xms and -Xmx ( heap) and PermGen and MaxPermGen should be different. (MaxPermGen =256 by default)