UNIX Operating Systems only A comprehensive performance report tool as such has not been created for the Windows platform, however various tools are available and will be separately documented to assist clients in monitoring and analyzing Blackboard performance on their systems.
General Information
This is a description of the Performance Report tool and how to use it. The Performance Report is a collection of tools gathering valuable information about your application server’s and database’s current activity for the purpose of analyzing performance issues. A Performance Report is an indispensable piece of information to be submitted with every performance-related trouble ticket, and it should be run whenever a performance problem is observed – both for system-wide and functionality-specific slowdowns.Usage Instructions
- You should run an initial performance report when there is no problem to use as baseline for comparison with later reports at problem times, and also to verify that everything works correctly. Contact Support if you have issues, e.g. if the tomcat thread dump is missing from the report or there are database errors in the final section. These issues need to be corrected before the performance problems arise that you want investigated!
- The Performance Report tool resides in /usr/local/blackboard/tools/perf_reports and is executed by running run_reports.sh from within that directory as bbuser (or as root).
- Output is stored in logs/perf_reports, which the tool will create, if it does not exist. These logs are then made available for download via the web interface from “Admin Panel > Logs > Download System Logs”.
- You need to have permissions to write to the blackboard logs/ directory and the perf_reports/ directory within it, to execute sqlplus and the various shell scripts, and to send a signal to the tomcat process, so you need to be eitherrootorbbuser to run this successfully.
- Previous to release 9.0, the tomcat thread dump is written to the file blackboard/logs/tomcat/catalina.out which must exist and must be the STDOUT of the tomcat JVM process. If you remove it (e.g. via custom log rotation methods), no thread dump or other error logging can be obtained, so this must not be done. Safe log rotation copies the file and then zeroes it out in place. This file also must be owned by the bbuser account.
- Since release 7.3, tomcat thread dumps can also be obtained separately via ServiceController.(sh|bat) services.appserver.threaddump which creates a timestamped output file in logs/tomcat/ (and if tomcat clustering is enabled, also in apps/tomcat/cluster/$node/logs). Since release 9.0, this is the method used by the Performance Report tool as well, and the thread dump output is not collected into the logs/perf_reports/report$timestamp.txt output file anymore, so now one must in addition to this file also provide the latest thread dump file from logs/tomcat/.
- Note that you should never run two performance reports simultaneously (even on multiple appservers) to avoid ugly Oracle errors upon creation of the intermediate table used by the tool. It is however perfectly safe to run the get_tomcat_trace.sh or get_os_stats.sh scripts on multiple appservers at once.
- Running the tool on a regular basis will skew the reported results on queries hogging disk and memory resources, as well as performance related tuning suggestions, so this is not recommended. It should only be run once or twice under normal usage conditions, then be reserved for troubleshooting performance-related problem situations.
- Also note that before this tool can successfully get anything at all from the DB, the BBADMIN user must have been granted access to the Oracle data dictionary, i.e. the SYS schema. On Oracle 8i he has this access by default, but on 9i you need to either run the DB with O7_DICTIONARY_ACCESSIBILITY=TRUE initialization parameter (this requires a DB restart) or to run GRANT SELECT ANY DICTIONARY TO BBADMIN; or even just GRANT SELECT_CATALOG_ROLE TO BBADMIN; while logged in as SYSDBA.
- Better database report tools exist and are commonly available – the Unix performance report is a rather outdated tool. For more useful database reports, please gather an AWR report from the problem time, or a statspack report if AWR is not licensed (statspack must have been installed first, see Oracle documentation). An ADDM report is also useful (in addition to an AWR report, not replacing it).;