• Xmx: 

Can be used to set maximum java heap size that can be used by the program. A low value can cause frequent OutOfMemory errors which might make the FioranoMQ server unreliable or low performance if the program's heap memory is reaching the maximum heap size as the GC will be run more frequently.

You may see the amount of memory you use exceeds the amount specified for the Xmx parameter. While Xmx limits the java heap size, java will allocate memory for other things, including a stack for each thread. It is not unusual for the total memory consumption of the VM to exceed the value of –Xmx.

Defaultvalueforfmqserveris256 MB

Example: -Xmx256m sets maximum heap size to 256 MB

• Xms: 

Can be used to set initial java heap size to be used by the program. This is useful if the program consumes a large amount of heap memory right from the start. This avoids the JVM to be constantly increasing the heap resulting in better performance.

Defaultvalueforfmqserveris128 MB

Example: -Xms128m sets minimum heap size to 128 MB
The value must be a multiple of, and greater than, 1024 bytes (1KB).

Stack Size settings

Xss: Can be used to set the java thread stack size. Each thread in the JVM is allocated a stack. The stack size limits the number of threads per JVM. If the stack size it too large, it will result in memory running out as each thread is allocated more memory than required. If the stack space is too small, there will eventually be an exception "Stack Overflow" error. If the stack space is too large, there will eventually be an exception similar to "Unable to create native thread", if the server tries to create more threads.

Jconsole

Local monitoring with jconsole is useful for development and prototyping. Using jconsole locally is not recommended for production environments, because jconsole itself consumes significant system resources. Rather, use jconsole on a remote system to isolate it from the platform being monitored.

To enable monitoring and management from remote systems, set this system property when you start the JVM: 
com.sun.management.jmxremote.port=portNum

Where, portNum is the port number through which you want to enable JMX/RMI connections.  Be sure to specify an unused port number.

For more information on usage of jconsole refer to http://download.oracle.com/javase/1.5.0/docs/guide/management/jconsole.html

PermGen space

The permanent generation is used to hold reflective objects of the VM such as class objects and method objects. These reflective objects are allocated directly into the permanent generation, and it is sized independently from the other generations.

• -XX: PermSize: This option is used to set a new initial size on Sun JVM when starting the virtual machine.
• -XX:MaxPermSize: This option is used to set the maximum permanent generation size.

When the number of components launched in-memory increases, so do the number of classes loaded. Perm Gen spacestoresthemetadataoftheJVM and is not part of the Heap space.

-d64

Specifies whether the program is to be run in a 32-bit or 64-bit environment if available. If neither -d32 nor -d64 is specified, the default is to run in a 32-bit environment, except for 64-bit only systems.

Garbage Collection

• -Xnoclassgc: This is used to disable class garbage collection.

This may lead to irrecoverable out of memory errors, and unless the reason for setting this flag is known thoroughly along with the consequences, setting this flag is not recommended.

• -XX:MaxGCPauseMillis: Sets the maximum desired number of milliseconds the garbage collector can pause the VM. This is only respected for the "throughput collector" or "parallel collector." In CMS, it has no effect. There is no default for this setting, so it has to be set for the garbage collector to meet a particular goal. However, it tries to meet this goal before meeting the GCTimeRatio goal.
• -XX:GCTimeRatio: Sets a goal for the throughput collector to avoid spending more than a certain amount of time doing garbage collection.

By default the value is 99, meaning the application should get at least 99 times as much time as the collector. That is, the collector should run for not more than 1% of the total time.

• -XX:-DisableExplicitGC: Disable calls to System.gc(), JVM still performs garbage collection when necessary.

It is dangerous for a misbehaving in-memory component to continuously issue System.GC calls when the Heap memory allocated is large. This option will disable actions against explicit calls. The memory of the server is best managed by the VM.

GC Algorithms

• -XX:+UseConcMarkSweepGC: This concurrent low pause collector is used to collect the tenured generation and does most of the collection concurrently with the execution of the application. The application is paused for short periods during the collection. The application is paused for short peiods during the collection. A parallel version of the young generation copying collector is used with the concurrent collector.
  Works well for long running servers with a large heap memory that can afford to share CPU cycles with the garbage collector. Would result in the lowest pause times.

• -XX:+CMSIncrementalMode: This flag enables the incremental mode.

  Icon

  This worksonlywhenconcurrentcollectorisenabled.

  For systems with 1 or 2 processors, this might make CMS run more smoothly and avoid concurrent mode failures because it actually does tiny stop-the-world phases to do some of its concurrent work instead of relying on the OS to give it an appropriate time-slice for a thread.

• -XX:+UseParallelGC: Selects the parallel garbage collector for the new generation of the Java heap . This collector is also referred to as the throughput collector. It uses a parallel version of the young generation collector. The old (tenured) generation is still cleaned with the default collector.
  
  By default on a host with N CPUs, the parallel garbage collector uses N garbage collector threads in the collection. The number of garbage collector threads can be controlled with a command line option -XX:ParallelGCThreads=<desired number>

  Icon

  -XX:+UseParallelGC should not be used with -XX:+UseConcMarkSweepGC .

GC logging

• -Xloggc:filename: Directs a smaller set of data to a file specified by filename. For every garbage collection, the following six fields are printed to the log file:
  • Cumulative time since data collection began (in seconds)
  • Garbage collection type
  • Heap in use before the GC event
  • Heap in use after the GC event
  • Current maximum heap size
  • Duration of the GC event
• -XX:+PrintGCDetails: More data is available if you start the JVM with the -XX:+PrintGCDetails or -XX:+PrintHeapAtGC options.
  Instructs the VM to be more verbose when printing out garbage collection data. Specifically it does not only tell you that there was a collection, but also what impact it had on the different generations. This flag is very useful when tuning generation sizes. In conjunction with -Xloggc this is the best setting for the free GCViewer.

• -XX:+PrintGCDetails -Xloggc: filename prints the details into file with name specified by filename
• -XX:+PrintGCTimeStamps: Prints the times at which the GC happens relative to the start of the application. Available only from J2SE1.4.0
• -XX:+PrintTenuringDistribution: This it used to generate the aging information of objects in young generation. It shows the threshold and the ages of objects in the new generation. It is also useful for observing the lifetime distribution of an application.

Heap Dump Settings

• -XX:HeapDumpPath: By default the heap dump is created in a file called java_pid<pid>.hprof in the working directory of the VM, where <pid> is the process ID. You can specify an alternative file name or directory with this option. This option is available only after JVM version 1.5 update 7 and above.
  For example, -XX:HeapDumpPath=~/dumps will cause the heap dump to be generated in the ~/dumps directory.
• -XX:+HeapDumpOnOutOfMemoryError: This VM option tells the VM to generate a heap dump when OutOfMemoryError is thrown because the java heap or the permanent generation is full. A heap dump is useful in production systems where you need to diagnose an unexpected failure.

Debugging

• -XX:+PrintConcurrentLocks: This will cause the Ctrl-Break handler to print a list of concurrent locks owned by each thread
• -XX:+PrintClassHistogram: This will cause the Ctrl-Break handler to print a heap histogram.
• -XX:+TraceClassLoading: This is used to trace loading of classes.
• -XX:+TraceClassUnloading: This is used to trace unloading of classes.

CoreDump on Application or JVM Error

-XX:ErrorFile=filename: If an error occurs, it saves the error data to the file specified where filename is the file location where error data need to be stored.