When a J2EE (ColdFusion, JBoss etc) crash occurs, before restarting, create a log set. If, after restarting, FusionReactor rotates the log files, data may be lost. The files in the FusionReactor log folder should be zipped up, or at least copied and saved. Your J2EE log files (typically ColdFusion/logs/*) and container log files (/ColdFusion8/runtime/logs) should also be saved.
FusionReactor has several settings pages that allow you to do things from selecting how much metric data to view on the Y axis to defining what percentage of memory usage you consider critical. Below is a list of configuration guides for all these types of settings that can help you diagnose problems.
- Request Settings
- Enterprise Settings
- Metrics Settings
- Resource Settings
- Crash Protection Restrictions
- Crash Protection Settings
- JDBC Settings
- JDBC Stack Trace Filter
- Compression Settings
- MIME Type Restrictions
- Exclude URLs
- Log Settings
- Search and Replace
- Filter Restrictions
- Filter Settings
- Filter Restrictions
FusionReactor stores a number of logs in memory, in order to produce useful metrics and graphs. These metrics will be your first point of observation to address issues on an ailing server. The Resource and Request logs are important to diagnose server problems, since they record the memory/CPU usage of the system and the running requests respectively. They are potentially very useful in an unstable environment, where restarts will cause FusionReactor to lose its in-memory data. All logging within FusionReactor is a computationally inexpensive operation, the limiting factor being available disk space. For detailed information about how the logging system works, please read the Overview of FusionReactor Logs.
Memory should be your first observation. If the blue chart of the Memory Usage bar is consistently near the top of the graph, consider making more memory available to the J2EE (ColdFusion) process. This can be altered within the ColdFusion Administrator in the section Server Settings -> Java and JVM -> Maximum JVM Heap Size. If there is insufficient memory on the system to increase the JVM memory, consider reducing the size of the Template Cache and Cached Queries.
A sawtooth pattern in the blue memory graph is normal. This shows Java periodically garbage collecting objects. When used memory begins to approach the allocated memory value, you may see one or more sawtooth (garbage collection) patterns, as Java attempts to reclaim memory before asking for more. If insufficient memory is reclaimed, you will see the white allocated memory bound increase, as Java demands memory from the operating system. If the blue portion steadily rises over the course of an hour, this often indicates a memory leak. These are becoming more common as the complexity of J2EE applications increases.
If the used memory (blue) graph is growing rapidly, you can try to ask Java to perform garbage collection yourself by clicking on the trash can icon on the Memory Usage graph. However, Java's memory algorithm is very sophisticated and it's unlikely a manual collection will have any significant effect.
CPU Usage is another useful metric. If the instance is consistently busy (see the blue line on the Memory Usage chart) with low load (see Request Activity graph), this might indicate a problem with the pages being run (see Request History), such as infinite loops or runaway queries (consider using the FusionReactor JDBC Driver Wrapper to analyze and prevent JDBC problems).
The Metrics -> Longest Requests page shows the longest running requests. FusionReactor also flags long-running requests with an appropriate label in the Request History table. You can configure what FusionReactor considers a long-running request, and how many to store in the Longest Requests table, in the Metrics Settings page.