In the IBM TRIRIGA Administrator Console, under Performance Monitor > Monitor a Single Value, several monitors are no longer listed.
The following changes were made in the Administrator Console, under Performance Monitor > Monitor a Single Value:
- CRYSTAL_QUEUE_AGENT_RUNNING is renamed to REPORT_QUEUE_AGENT.
- CLEANUP_AGENT_RUNNING is renamed to PLATFORM_MAINTENANCE_SCHEDULER.
- KEYWORD_PARSER_AGENT_RUNNING and WAREHOUSE_AGENT_RUNNING were deprecated in a previous release and are now removed from the Performance Monitor.
Since the CRYSTAL_QUEUE_AGENT_RUNNING and CLEANUP_AGENT_RUNNING monitors are used for integration, only the performance monitor names are changed, not the values or URLs.
[Admin: This post is related to the 07.14.15 post about renaming CleanupAgent (Cleanup Agent) to PlatformMaintenanceScheduler (Platform Maintenance Scheduler). To see other related posts, use the Monitoring tag.]
Is anyone familiar with this error?
5/20/17 1:03:36:364 EDT] 000000b8 ThreadMonitor W WSVR0605W: Thread "server.startup : 2" (00000072) has been active for 712611 milliseconds and may be hung. There is/are 1 thread(s) in total in the server that may be hung.
[Admin: To see other related posts, use the Thread tag.]
In the Admin Console, Performance Monitor, when monitoring a single value, it returns bad results. Returns wrong agent’s status. Returns “false” for an agent status even if the agent is running. Returns “0” for the number of agents running even if multiple agents are running.
We needed to update the calls to various platform status APIs. Moving forward, we updated the Admin Console, Performance Monitor, Single Value to correctly obtain the status of the active agents. This means the AGENTS_RUNNING_COUNT, OBJECT_PUBLISH_AGENT_RUNNING, SCHEDULER_AGENT_RUNNING, and all other agent-related monitors will now correctly report the agent status and count. We also removed the calls to KEYWORD_PARSER_AGENT_RUNNING and WAREHOUSE_AGENT_RUNNING as these no longer exist.
[Admin: This post is related to the 04.08.15 post about performance monitoring tools, and the 02.10.17 post about performance best practices.]
I have installed TRIRIGA 10.5.2/3.5.2 OOB in Sandbox 1. One thing I noticed is that I used to be able to run the TRIRIGA service as “SVC-CBRES-IWMS-DEV” and I used to display the following in a web page, but in 3.5.2, I am not getting the expected “Sign In Required” error.
In TRIRIGA 3.5.2, a security change was filtering out the Performance Monitor (Single Values) URL. We needed to remove the filtering of monitor.jsp. Moving forward, a security issue was fixed which made the performance monitors unable to work externally from the TRIRIGA Admin Console.
[Admin: This post is related to the 04.08.15 post about performance monitoring tools.]
In the TRIRIGA 3.5 platform release, a new feature was added allowing you to track the performance and monitor who runs queries and reports in Report Builder. A flag can be set on the report definition that will track who has run the report, and the time it took to retrieve the information from the database.
To enable report run history, open the report in the Report Manager and click “Track History” on the General tab. Note that enabling this tracking causes just a slight overhead, but it should still be used with caution. Once enabled, you will need to let your users use the system for a while, so that some data can be saved. Once a few days goes by, you can then start to analyze what is happening in your system…
- Which reports have run the longest overall?
- Of the reports that have run, which have the average longest runtime?
- For the users in the system, who runs the most reports?
- Of the users in the system, who have run the longest reports?
To address performance-related issues in the installation of the TRIRIGA Application, this article provides suggestions and recommendations for the IBM TRIRIGA MS SQL Server database environment. It also provides monitoring and troubleshooting steps to quickly discover and prevent performance and instability degradation… This article addresses the following key areas:
- General best practices
- TRIRIGA-specific recommendations
- Performance monitoring
- Problem resolution…
MS SQL Server performance problems can be difficult to pinpoint and require inspection into many aspects of the environment. There is no magic button or specific step-by-step actions to locate every performance issue. Instead, there are guidelines for diagnosing and troubleshooting common performance problems. This article will provide a general methodology for diagnosing and troubleshooting MS SQL Server database instability and performance problems in common scenarios.
Configuration, tuning, and sizing issues for MS SQL Server may lead to various instability and performance issues from the database end. The instructions listed below should be reviewed, confirmed, and applied by the customer’s database administrator whenever necessary… Here are some basic best practices that should be implemented on production MS SQL Server environments…
[Admin: To see other related posts, use the Best Practices tag.]