5 Replies Latest reply: Jun 21, 2012 2:39 AM by Wolf-Dieter Fink RSS

    Not specifying an -Xms value

    Clayton Covell Newbie

      One of our developers today tried to convince me by not setting the -Xms parameter, our development JVMs will perform much better.  I have always followed the advise of setting the -Xms equal to the -Xmx value and was wondering if there is any truth to what my developer claims.

        • 1. Re: Not specifying an -Xms value
          Wolf-Dieter Fink Master

          JVM setting, specialy memory heap and gc, depends on the application and the JVM.

          If you have the right heap size -Xms and -Xmx can be set to the same value, this is to avoid recalculating and allocate/free physical memory  (Oracle JVM).

          Less size of the heap might be end in a better performance and the JVM decide to not use the maximum of what you set.


          So you should monitor the JVM and GC behaviour in production and adjust the parameters here. Also, from my experience, it makes no sense to tune with a lot of effort because change of the throughput can change everything.

          • 2. Re: Not specifying an -Xms value
            Peter Johnson Master

            My recommendation is to not set -Xms the same as -Xmx on a development machine. Why? On such a machine you run numerous things, not just JBoss AS. In that event you want to use a little of your available memory as possible - most likely you won't be running the app server long enough for it to want to grab the rest of the memory for the heap.


            On a production machine, always set -Xms to the same as -Xmx. Why? Because a production machine is tpyically a one-use machine (that is, other than the OS, only the app server will be running). And after runnign a while the app server will have grabbed all of the heap memory, and won't let it go. So you might as well give it all the heap memeory to start with. (There is also a small performance penalty for making the JVM continually ask the OS for more heap space, and also for causing the JVM to determine whether it needs nor space or can give space away. Setting -Xms and -Xmx to the same value avoids performing those calculations. But the performance difference on modern processors and RAM configurations is negligible.)

            • 3. Re: Not specifying an -Xms value
              Clayton Covell Newbie

              I understand the need to change the configuration in a development machine versus a production machine, but this development machine is soley used for host JBoss JVMs (there are six).  I was curious about what would happen by not specifying the -Xms.

              • 4. Re: Not specifying an -Xms value
                Peter Johnson Master

                So you are running six copies for the app server at the same time?


                I'm a little rusty on this (its been years since I looked at JVM memory management in detail), but if I recall correctly, when a JVM starts up it asks the OS if it can reserve the amount of memory specified by -Xmx. If if can't it won't run. If it can, it then requests only -Xms memory for the heap. This can lead to a possible OOME later down the line if you don't have sufficient memory (RAM + swap) to hold -Xmx for all 6 app servers.

                • 5. Re: Not specifying an -Xms value
                  Wolf-Dieter Fink Master

                  I'm not sure about all JVM implementations but as far as I remember, I checked only my JDK6/7 on Fedora but worked also with Sun/HP, the OS will allocate the amount of -Xms and increase it very fast if you load big applications.

                  But it need a bit warmup to reach -Xmx, also it is possible that the JVM free memory if the servers throughput is less in off-peak phases.


                  So I strongly agree to Peter's statement how to set the parameter in dev/prod.


                  What you should never do is to set the sum of all servers (-Xmx + -MaxPermSize + ThreadStackSize) to an amount near or above the physical memory. This will end up in a worst performance because of swapping.