7

I have a jvm server in my machine, now I want to have 2 apservers of mine sitting in same machine, however I want the standby one to have a really low amount of memory allocated with xmx because its passive, one the main server (active) goes down I want to allocate more memory to my passive server which is already up without restarting it (I have have them both having too much xmx - note they would consume memory at startup and I cant allow possibility of outOfMemory).

So I want passive - low xmx once active goes down I want my passive to receive much more xmx.

is there a way for me to achieve that. Thanks

Jas
  • 14,493
  • 27
  • 97
  • 148

4 Answers4

5

It would be nice, but as far as I know it's not an option with the Sun provided JVMs.

The Xmx option is to specify maximum memory, it's there to prevent the JVM from consuming the entire machine's free memory. If you want to set it higher, it won't require the JVM allocate all of that memory. Why not just set it to a very high number and let the JVM grow into it over time?

To make sure your JVM doesn't start off with too little memory (creating lots of pauses as it grows the memory to the required size), adjust Xms to the size you want to allocate for the JVM at startup.

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • it won't require the JVM allocate all of that memory. - I understand that but once I tell the jvm XMX=somevalue then in my view the JVM is *allowed* to consume that and I cannot even let the smallest chance it would require it (see my prev comment). – Jas May 27 '10 at 06:54
  • 4
    @Jas I find that in practice, the JVM will use everything you tell it to use. Even if you only have 10 MB of hard-referenced objects, if you give it -Xmx100G, it will use the 100G up even if almost all the objects in memory can be collected. And this is the reason they make us specify it - because they don't know how to manage the memory well enough to make it just grow automatically. – Hakanai Apr 02 '14 at 04:38
3

The short answer is unless your particular JVM allows for these values to be changed after initialization, you cannot (I believe this is the case for HotSpot).

However, you may be able to accomplish your goals without changing Xmx on the fly. For example, you could use a small -Xms setting, but keep -Xmx relatively high. If the passive server is not using much memory / generating garbage while still serving as the backup, then memory will stay near the Xms value. However, once the backup server takes over it would be allowed to expand allocated memory up to the Xmx value on an as-needed basis.

See java (windows) or java (*nix) as appropriate (though -Xms and -Xmx have the same general meaning on all platforms).

Greg Case
  • 46,881
  • 3
  • 27
  • 21
2

You don't need to adjust Xmx on the standby instance as long as it's not doing anything (or much of anything) because it should stay close to the value you set with Xms until it starts doing real work.

The Xmx switch governs the maximum amount of heap size the Java instance may consume. Xms governs the startup amount.

If you set Xms small on your standby instance and Xmx to whatever maximum your program needs, and then switch over to the Standby instance (killing the regular instance) it should work out fine.

It may be necessary to actually stop/kill the regular Java process depending on your available memory in order for the standby process to allocate all of the heap it needs as it moves from the initial lower heap size to toward it's maximum.

Eric J.
  • 147,927
  • 63
  • 340
  • 553
  • once I tell the JVM XMX= then in my view I don't have any control over it and I cannot be 100% the jvm won't use the memory, who knows maybe the jvm will decide after some time it wants memory - after all i'm not in control of it and i cannot allow any chance even if its 1% chance that the jvm will decide it needs more memory - its doing many things internally, maybe it would decide it needs more without my application needing more, my standby app server has a few threads its not like a totally frozen app... – Jas May 27 '10 at 06:53
  • so my fear is that although I specify high XMX and its a standby at some point the standby would reach that memory *just because* the jvm will decide it needs it (maybe it has some algorithm i'm not aware of). – Jas May 27 '10 at 06:53
  • 1
    @Jason just try it out with the specific JVM you're using. You can run an external monitor (see hyperic.org for a good open source one) that tracks JVM memory usage and a lot of other stats. Hyperic can alert you if the standby one starts to consume more memory. – Eric J. May 27 '10 at 15:25
  • You can also use `-XX:MaxHeapFreeRatio` to persuade JVM to release unused heap back to OS. – Piotr Findeisen Oct 05 '13 at 01:22
0

For the JVM to fill all the heap, you'd have to generate enough objects that survive the young generation collection. That would be unlikely on the lightly-loaded stand-by server.

To improve your chances of catching all the garbage in the young generation, configure your young generation heap accordingly: larger sizes, more generations before objects age out. This is a compromise between confining your standby server to young generation and the collection profile you need in your primary server.

Update: the new G1 collector uses different configuration options. PLease look at http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html to learn more. The option most relevant to your case would be

-XX:InitiatingHeapOccupancyPercent=45 - Percentage of the (entire) heap occupancy to start a concurrent GC cycle. It is used by G1 to trigger a concurrent GC cycle based on the occupancy of the entire heap, not just one of the generations. A value of 0 denotes 'do constant GC cycles'. The default value is 45 (i.e., 45% full or occupied).

IOW, the equivalent of young generation collection will start when the current heap (the min heap size initially) is 45% used up. Your light-load server should never leave the min heap size (unless it produces relatively long-living objects, in which case see -XX:MaxTenuringThreshold).