| Skip Navigation Links | |
| Exit Print View | |
|
Oracle GlassFish Server Message Queue 4.5 Administration Guide |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Part I Introduction to Message Queue Administration
1. Administrative Tasks and Tools
3. Starting Brokers and Clients
6. Configuring and Managing Connection Services
8. Configuring Persistence Services
9. Configuring and Managing Security Services
10. Configuring and Managing Broker Clusters
11. Managing Administered Objects
12. Configuring and Managing Bridge Services
13. Monitoring Broker Operations
14. Analyzing and Tuning a Message Service
A Client Cannot Establish a Connection
Connection Throughput Is Too Slow
A Client Cannot Create a Message Producer
Message Production Is Delayed or Slowed
Messages Are Not Reaching Consumers
Dead Message Queue Contains Messages
To Inspect the Dead Message Queue
17. Broker Properties Reference
18. Physical Destination Property Reference
19. Administered Object Attribute Reference
20. JMS Resource Adapter Property Reference
21. Metrics Information Reference
22. JES Monitoring Framework Reference
A. Distribution-Specific Locations of Message Queue Data
B. Stability of Message Queue Interfaces
Symptom:
Message throughput sporadically drops and then resumes normal performance.
Possible causes:
JVM memory reclamation (garbage collection) is taking place.
The JVM is using the just-in-time compiler to speed up 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:
-vmargs -verbose:gc
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:
-XX:+UseParallelGC=true
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.
|