|Skip Navigation Links|
|Exit Print View|
|Oracle GlassFish Server Message Queue 4.5 Administration Guide|
Message throughput sporadically drops and then resumes normal performance.
Possible cause: The broker is very low on memory resources.
Because destination and broker limits were not properly set, the broker takes increasingly serious action to prevent memory overload; this can cause the broker to become sluggish until the message backlog is cleared.
To confirm this cause of the problem: Check the broker log for a low memory condition
[B1089]: In low memory condition, broker is attempting to free up resources
followed by an entry describing the new memory state and the amount of total memory being used. Also check the free memory available in the JVM heap:
imqcmd metrics bkr -m cxn
Free memory is low when the value of total JVM memory is close to the maximum JVM memory value.
To resolve the problem:
Adjust the JVM (see Java Virtual Machine Adjustments).
Increase system swap space.
Possible cause: JVM memory reclamation (garbage collection) is taking place.
Memory reclamation periodically sweeps through the system to free up memory. When this occurs, all threads are blocked. The larger the amount of memory to be freed up and the larger the JVM heap size, the longer the delay due to memory reclamation.
To confirm this cause of the problem: Monitor CPU usage on your computer. CPU usage drops when memory reclamation is taking place.
Also start your broker using the following command line options:
Standard output indicates the time when memory reclamation takes place.
To resolve the problem: In computers with multiple CPUs, set the memory reclamation to take place in parallel:
Possible cause: The JVM is using the just-in-time compiler to speed up performance.
To confirm this cause of the problem: Check that none of the other possible causes of this problem are responsible.
To resolve the problem: Let the system run for awhile; performance should improve.