I have always given an assumed heap size to my application and while the app is running, I monitor and modify / tune the heap size.
Is there a way in which I can calculate the initial heap required more or less accurately.
For the best performance in a Java EE style environment, i.e. when the application is meant to be running for very long periods of time (months or weeks), then it is best to set the minimum and maximum heap size to be the same.
The best way to size the heap in this case is to gather data on how your application runs over time. With a weeks worth of verbose GC log, we can import that data into GCViewer. Looking at the troughs of the graph, we can take an average and see the minimum retained set after each garbage collection. This is the amount of data, on average, kept in the heap for normal running. So any heap size should be at least that level. Since we're setting minimum and maximum to the same here, we need to add more space to compensate for spikes. How much to add depends on your use case, but somewhere between 25-35% is a start.
With this method, always remember to keep monitoring your heap and GC behaviour using verbose GC (which is recommended by Oracle to run even in production).
Important: This is assuming that your application is an always-on type of application. If you're considering a desktop java application, then the behaviour will be very very different and this should not be seen as a reliable method in that case. As #juhist said in his/her answer, just the maximum should be set and the JVM will handle the rest.
Why do you monitor and modify / tune the heap size?
Java has been designed in a way that the heap automatically grows to the needed size as long as the maximum heap size is large enough. You shouldn't modify the heap size manually at all.
I would rely on the automatic Java algorithms for adjusting the heap size and just specify the maximum heap size at program startup. You should take into account how many java processes you're running in parallel when deciding the maximum heap size.
Related
Why does the JVM have an -Xms option? Why do we care about a minimum heap size? Why not just 0? It's super easy to allocate RAM, so I don't see the point of forcing a minimum heap size.
In my searching, I see that it's customary to set -Xms (minimum heap size) and -Xmx (maximum heap size) to the same value.
I am having a hard time finding a clear and rational basis for this custom or why -Xms even exists. Rather, I find a lot of communal reinforcement. On occasion, I see it justified by a flaky theory, such that the JVM is unusually slow at allocating additional RAM as it grows the heap size.
While this came up as I was optimizing Solr, it seems that fussing with the heap size is a common consideration with JVMs.
As a curious data point, you'll see two memory-usage dips here:
Before dip 1: -Xms14g -Xmx14g
Between dip 1 and 2: -Xms0g -Xmx14g
After dip 2: -Xmx14g
After dip 2, Solr reported to me that it was only using a couple hundred MBs of heap space even though the JVM gobbled up many GBs of RAM.
In case it matters, I am on the current release of OpenJDK.
To summarize, is there a rational and fact-based basis for:
Setting -Xms to something other than 0.
The custom of setting -Xms and -Xmx to the same value.
Why -Xms even exists.
I think the fact-based basis will help with a more informed basis for managing heap-size options.
You have three questions.
First question:
Is there a rational and fact-based basis for setting -Xms to something other than 0?
Looking as far back as version 8, we can see (among other things) the following for -Xms:
Sets the minimum and the initial size (in bytes) of the heap.
So, setting -Xms to 0 would mean setting the heap to 0. I'm not sure what your expectation would be, but.. the JVM needs at least some amount of heap to do things (like run a garbage collector).
Second question:
Is there a rational and fact-based basis for the custom of setting -Xms and -Xmx to the same value?
Yes, if you expect to use a certain amount of memory over time, but not necessarily right away. You could allocate the full amount of memory up front so that any allocation costs are out of the way.
For example, consider an app that launches needing less than 1GB of memory, but over time it grows (normally, correctly) to 4GB. You could run that app with -Xms1g -Xmx4g – so, start with 1GB and do periodic allocations over time to reach 4GB. Or you could run with -Xms4g -Xmx4g – tell the JVM to allocate 4GB now, even if it's not going to be used right away.
Allocating memory from an underlying operating system has a cost, and might be expensive enough that you'd like to do that early in the application life, instead of some later point where that cost might be more impactful.
Third question:
Is there a rational and fact-based basis for why -Xms even exists?
Yes, it allows tuning JVM behavior. Some applications don't need to do this, but others do. It's useful to be able to set values for lower, upper, or both (lower and upper together). Way beyond this, there's a whole world of garbage collector tuning, too.
A little more detail on how -Xms is used (below) could give you some initial garbage collection topics to read about (old generation, young generation):
If you do not set this option, then the initial size will be set as the sum of the sizes allocated for the old generation and the young generation.
I have troubles with Java memory consumption.
I'd like to say to Java something like this: "you have 8GB of memory, please use it, and only it. Only if you really can't put all your resources in this memory pool, then fail with OOM".
I know, there are default parameters like -Xmx - they limit only the heap. There are also plenty of other parameters, I know. The problems with these parameters are:
They aren't relevant. I don't want to limit the heap size to 6GB (and trust that native memory won't take more than 2GB). I do want to limit all the memory (heap, native, whatever). And do that effectively, not just saying "-Xmx1GB" - to be safe.
There is too many different parameters related to memory, and I don't know how to configure all of them to achieve the goal.
So, I don't want to go there and care about heap, perm and whatever types of memory. My high-level expectation is: since there is only 8GB, and some static memory is needed - take the static memory from the 8GB, and carefully split the remaining memory between other dynamic memory entities.
Also, ulimit and similar things don't work. I don't want to kill the java process once it consumes more memory than expected. I want Java does its best to not reach the limit firstly, and only if it really, really can't - kill the process.
And I'm OK to define even 100 java parameters, why not. :) But then I need assistance with the full list of needed parameters (for, say, Java 8).
Have you tried -XX:MetaspaceSize?
Is this what you need?
Please, read this article: http://karunsubramanian.com/websphere/one-important-change-in-memory-management-in-java-8/
Keep in mind that this is only valid to Java 8.
AFAIK, there is no java command line parameter or set of parameters that will do that.
Your best bet (IMO) is to set the max heap size and the max metaspace size and hope that other things are going to be pretty static / predictable for your application. (It won't cover the size of the JVM binary and it probably won't cover native libraries, memory mapped files, stacks and so on.)
In a comment you said:
So I'm forced to have a significant amount of memory unused to be safe.
I think you are worrying about the wrong thing here. Assuming that you are not constrained by address space or swap space limitations, memory that is never used doesn't matter.
If a page of your address space is not used, the OS will (in the long term) swap it out, and give the physical RAM page to something else.
Pages in the heap won't be in that situation in a typical Java application. (Address space pages will cycle between in-use and free as the GC moves objects within and between "spaces".)
However, the flip-side is that a GC needs the total heap size to be significantly larger than the sum of the live objects. If too much of the heap is occupied with reachable objects, the interval between garbage collection runs decreases, and your GC ergonomics suffer. In the worst case, a JVM can grind to a halt as the time spent in the GC tends to 100%. Ugly. The GC overhead limit mechanism prevents this, but that just means that your JVM gets an OOME sooner.
So, in the normal heap case, a better way to think about it is that you need to keep a portion of memory "unused" so that the GC can operate efficiently.
So, after asking this question, it quickly became clear that the important question was not "how can I", but "should I"?
We have customers that we are moving from Java7 to Java8 (using Tomcat7). Java7 required setting the -XX:MaxPermSize, and some customers have increased their max above the default set by the installer due to individual needs and uses.
Should I set the -XX:MaxMetaspaceSize (to the previous -XX:MaxPermSize setting) for customers who have defined a custom max? What about new installs? Should we set -XX:MaxMetaspaceSize at all?
What are the pros and cons of such a decision?
As I commented on the previous answer the reasons for setting a limit on those memory pools is different.
If your users previously increased the MaxPermSize above the default that probably was either to avoid Full GCs / concurrent mode failures with CMS or because their applications genuinely needed a lot of perm gen space.
Decreasing the the metaspace limit from its effectively infinite default would serve an entirely different purpose: Avoiding unbounded metaspace growth.
The thing is that that's just an upper limit. The actually committed, i.e. current metaspace size will be smaller. In fact, there is a setting called MaxMetaspaceFreeRatio (default 70%) which means that the actual metaspace size will never exceed 230% of its occupancy.
And for it to grow it first would have to fill up, forcing a garbage collection (metaspace full) in an attempt to free objects and only when it cannot meet its MinMetaspaceFreeRatio (default 40%) goal it would expand the current metaspace to no more than 230% of the occupancy after the GC cycle.
So in practice the actual metaspace size should stabilize within a band close relative to its actual need unless the application is continuously leaking classloaders/classes or generating an enormous amount of dynamic code.
TL;DR: There may be reasons to restrict metaspace size, but they likely are different to the original reasons for setting the perm gen sizes. Therefore the need should be re-evaluated.
Just to air the opposite opinion, the case can be made to ALWAYS set the MaxMetaspaceSize. Grouping the world's entire set of applications into 10 (binary - think about it) groups allows a discussion of why. Remember though, setting the limit only controls when Garbage Collection (GC) of that space will occur.
Group 01: Applications with all Non-Dynamic Classes
This group puts you into the stabilized band referred to above. In this case, the size to set is fairly easy to determine (just as MaxPermSize was) and there won't be much, if any, GC anyway.
Group 10: Applications with Dynamic Classes
Given the proliferation of highly powerful third party libraries, isn't almost every application in this group anyway? Often you don't care if the library is Scala/Groovy/etc, it just does exactly what you want so it is used. What is the value of filling up Metaspace with the litter of dead (dynamic) classes? When GC does come, it will be expensive. I would rather limit the size, make GC more frequent (but less pause time for each), and more easily run multiple applications on the same hardware without having concerns about their individual metaspaces running into one another.
Answer from #eckes comments:
i would set a maximum which is large enough to not trigger in normal
situations. The reason I say this is, that a system might act very
erratic and hard to control if native memory gets exhausted or wild
swapping happens. Much worse than a OOM or Java freeze. For example
using 2GB (epecting a system to have 2gb buffers free at minimum)
For a large data mining experiment run using Java (Weka), I am trying to assign a larger heap size as said to increase performance.
I do so by setting the following options in the menu 'Run > Run Configurations > Arguments':
[The application containing the code to be run indeed is the selected one].
Two things confuse me:
The performance doesn't increase at all. Might still be possible if additional memory doesn't make the program run faster?
Even if I set values that exceed my machines RAM (4096m) it does not yield any errors. Is that correct or should there be one?
Increasing memory will never increase the performance if your program does not need that much memory. So first make sure that your program needs that much memory.
Understand the meaning of xms and xmx
xms(initial heap size) is the initial heap size so system will allocate this much heap for initial use and by specifying xmx(maximum heap size) you are telling the system that this is the maximum heap size that you may be using. this is the reason why your system is not yielding any error.
Currently in our testing environment the max and min JVM heap size are set to the same value, basically as much as the dedicated server machine will allow for our application. Is this the best configuration for performance or would giving the JVM a range be better?
Peter 's answer is correct in that -Xms is allocated at startup and it will grow up to -Xmx (max heap size) but it's a little misleading in how he has worded his answer. (Sorry Peter I know you know this stuff cold).
Setting ms == mx effectively turns off this behavior. While this used to be a good idea in older JVMs, it is no longer the case. Growing and shrinking the heap allows the JVM to adapt to increases in pressure on memory yet reduce pause time by shrinking the heap when memory pressure is reduced. Sometimes this behavior doesn't give you the performance benefits you'd expect and in those cases it's best to set mx == ms.
OOME is thrown when heap is more than 98% of time is spent collecting and the collections cannot recover more than 2% of that. If you are not at max heaps size then the JVM will simply grow so that you're beyond that boundaries. You cannot have an OutOfMemoryError on startup unless your heap hits the max heap size and meets the other conditions that define an OutOfMemoryError.
For the comments that have come in since I posted. I don't know what the JMonitor blog entry is showing but this is from the PSYoung collector.
size_t desired_size = MAX2(MIN2(eden_plus_survivors, gen_size_limit()),
min_gen_size());
I could do more digging about but I'd bet I'd find code that serves the same purpose in the ParNew and PSOldGen and CMS Tenured implementations. In fact it's unlikely that CMS would be able to return memory unless there has been a Concurrent Mode Failure. In the case of a CMF the serial collector will run and that should include a compaction after which top of heap would most likely be clean and therefore eligible to be deallocated.
Main reason to set the -Xms is for if you need a certain heap on start up. (Prevents OutOfMemoryErrors from happening on start up.) As mentioned above, if you need the startup heap to match the max heap is when you would match it. Otherwise you don't really need it. Just asks the application to take up more memory that it may ultimately need. Watching your memory use over time (profiling) while load testing and using your application should give you a good feel for what to need to set them to. But it isn't the worse thing to set them to the same on start up. For a lot of our apps, I actually start out with something like 128, 256, or 512 for min (startup) and one gigabyte for max (this is for non application server applications).
Just found this question on stack overflow which may also be helpful side-effect-for-increasing-maxpermsize-and-max-heap-size. Worth the look.
AFAIK, setting both to the same size does away with the additional step of heap resizing which might be in your favour if you pretty much know how much heap you are going to use. Also, having a large heap size reduces GC invocations to the point that it happens very few times. In my current project (risk analysis of trades), our risk engines have both Xmx and Xms to the same value which pretty large (around 8Gib). This ensures that even after an entire day of invoking the engines, almost no GC takes place.
Also, I found an interesting discussion here.
Definitely yes for a server app. What's the point of having so much memory but not using it?
(No it doesn't save electricity if you don't use a memory cell)
JVM loves memory. For a given app, the more memory JVM has, the less GC it performs. The best part is more objects will die young and less will tenure.
Especially during a server startup, the load is even higher than normal. It's brain dead to give server a small memory to work with at this stage.
From what I see here at http://java-monitor.com/forum/showthread.php?t=427
the JVM under test begins with the Xms setting, but WILL deallocate memory it doesn't need and it will take it upto the Xmx mark when it needs it.
Unless you need a chunk of memory dedicated for a big memory consumer initially, there's not much of a point in putting in a high Xms=Xmx. Looks like deallocation and allocation occur even with Xms=Xmx