10

Does the Sun JVM slow down when more memory is available and used via -Xmx? (Assumption: The machine has enough physical memory so that virtual memory swapping is not a problem.)

I ask because my production servers are to receive a memory upgrade. I'd like to bump up the -Xmx value to something decadent. The idea is to prevent any heap space exhaustion failures due to my own programming errors that occur from time to time. Rare events, but they could be avoided with my rapidly evolving webapp if I had an obscene -Xmx value, like 2048mb or higher. The application is heavily monitored, so unusual spikes in JVM memory consumption would be noticed and any flaws fixed.

Possible important details:

  • Java 6 (runnign in 64-bit mode)
  • 4-core Xeon
  • RHEL4 64-bit
  • Spring, Hibernate
  • High disk and network IO

EDIT: I tried to avoid posting the configuration of my JVM, but clearly that makes the question ridiculously open ended. So, here we go with relevant configuration parameters:

-Xms256m 
-Xmx1024m 
-XX:+UseConcMarkSweepGC 
-XX:+AlwaysActAsServerClassMachine 
-XX:MaxGCPauseMillis=1000 
-XX:MaxGCMinorPauseMillis=1000 
-XX:+PrintGCTimeStamps 
-XX:+HeapDumpOnOutOfMemoryError
Stu Thompson
  • 38,370
  • 19
  • 110
  • 156

5 Answers5

6

By adding more memory, it will take longer for the heap to fill up. Consequently, it will reduce the frequency of garbage collections. However, depending on how mortal your objects are, you may find that how long it takes to do any single GC increases.

The primary factor for how long a GC takes is how many live objects there are. Thus, if virtually all of your objects die young and once you get established, none of them escape the young heap, you may not notice much of a change in how long it takes to do a GC. However, whenever you have to cycle the tenured heap, you may find everything halting for an unreasonable amount of time since most of these objects will still be around. Tune the sizes accordingly.

James
  • 2,050
  • 13
  • 15
  • Thanks. As you'll see from my edited question, I have set a maximum duration to the GC duration. While aware of the ability to tune tenured heap, etc., I have not gone there yet under the guise of "premature optimization". But maybe it makes sense...I can feel another SO question coming on! – Stu Thompson Apr 14 '09 at 19:54
4

If you just throw more memory at the problem, you will have better throughput in your application, but your responsiveness can go down if you're not on a multi core system using the CMS garbage collector. This is because fewer GCs will occur, but they will have more work to do. The upside is that you will get more memory freed up with your GCs, so allocation will continue to be very cheap, hence the higher througput.

You seem to be confusing -Xmx and -Xms, by the way. -Xms just sets the initial heap size, whereas -Xmx is your max heap size.

Kai
  • 3,997
  • 4
  • 30
  • 36
  • No, I have not confused the two parameters :) I just thought that was all that was relevant when originally posting the question--since updated. Thanks for the input! – Stu Thompson Apr 14 '09 at 19:47
  • @Stu Thompson: But you seem to be using the two interchangeably, so it's hard to tell which one you mean. – Michael Myers Apr 14 '09 at 19:51
  • 1
    Crap. You are right. I had a typo and put 'Xms' when I meant 'Xmx'. My apologies. – Stu Thompson Apr 14 '09 at 19:59
0

More memory usually gives you better performance in garbage collected environments, at least as long as this does not lead to virtual memory usage / swapping.

The GC only tracks references, not memory per se. In the end, the VM will allocate the same number of (mostly short-lived, temporary) objects, but the garbage collector needs to be invoked less often - the total amount of garbage collector work will therefore not be more - even less, since this can also help with caching mechanisms which use weak references.

I'm not sure if there is still a server and a client VM for 64 bit (there is for 32 bit), so you may want to investigate that also.

Lucero
  • 59,176
  • 9
  • 122
  • 152
  • Thanks for the input, but I am confident the rest of my configuration is good. And, even if it is flawed, I'd like to keep this question in the realm of "All things being equal..." – Stu Thompson Apr 14 '09 at 19:26
0

According to my experience, it does not slow down BUT the JVM tries to cut back to Xms all the time and try to stay at the lower boundary or close to. So if you can effort it, bump Xms as well. Sun is recommending both at the same size. Add some -XX:NewSize=512m (just a made up number) to avoid the costly pile up of old data in the old generation with leads to longer/heavier GCs on the way. We are running our web app with 700 MB NewSize because most data is short-lived.

So, bottom line: I do not expect a slow down, but put your more of memory to work. Set a larger new size area and set Xms to Xmx to lower the stress on the GC, because it does not need to try to cut back to Xms limits...

ReneS
  • 3,535
  • 2
  • 26
  • 35
0

It typically will not help your peformance/throughput,if you increase -Xmx. Theoretically there could be longer "stop the world" phases but in practice with the CMS that's not a real problem.

Of course you should not set -Xmx to some insane value like 300Gbyte unless you really need it :)

kohlerm
  • 2,596
  • 1
  • 17
  • 22