Product:TIBCO Spotfire Statistics Services
Versions:All
Summary:
TIBCO Spotfire Statistics Services (TSSS) server could sometimes get strained when the server is overloaded with many jobs or when there are some large jobs being executed. You can check the status and execution time of the jobs with TSSS API job URL, together with analysis of Spotfire Web Player logs to identify which jobs are straining the server.
Details:
A TIBCO Spotfire Statistics Service (TSSS) server may sometimes be strained with memory and CPU fully utilized. This article describes how to track memory and CPU usage for each job executed in TIBCO Spotfire Statistics Services.
Resolution:
(1) If you use a JMX-compliant monitoring tool such as TIBCO Hawk or JConsole, you can monitor the Statistics Service (TSSS) Server’s health and status including memory and CPU usage, edit the server configurations, and manage the job queues of Spotfire Statistics Services, all remotely.
Here is a document on TSSS Remote monitoring and management with JMX, for your reference:
https://docs.tibco.com/pub/sf_statsvcs/11.4.5/doc/html/TIB_sf_statsvcs_11.4.5_installation/installation/topics/remote_monitoring_and_management_with_jmx.html
----------------
Using remote management and monitoring through JMX, you can perform the following tasks:
Restart Manager or Worker nodes.
View and edit the server configuration.
Perform job and package management.
Manage nodes in a cluster
----------------
Such JMX monitoring tools could help you monitor the resource usage of TSSS service at all times and manage the running jobs when the resource usage is high.
(2) However, JConsole could track memory usage of an individual job, but each TSSS job runs in a separate (new) JVM and JConsole needs to connect to each JVM to gather statistics.
So you'd need to have some way to connect to each job JVM and monitor it, which would be hard to do and use it systematically.
CPU and memory usage for jobs executed in TSSS server are not logged specifically. Instead, the execution time it takes for TSSS service to run the jobs is however logged.
Reviewing the job history and job status with TSSS jobs API URL (http://<TSSSserver>:<port>/<ServiceName>/api/v8/jobs), can often be a good indicator of what is causing the system to slow down, especially if you know WHEN the system is being strained and can match that up to the job history.
Often (but not always) jobs that are using a lot of resources naturally take longer to run, so you can also just look for abnormally long running jobs, or jobs that seem to slow other jobs running at the same time down.
Even better, if you have job failures or jobs that are interrupted, that's a good indication from the job history that something's causing problems.
Then you do have to match those up to the Spotfire Web Player logs to figure out which user / data function is causing that, but that's just matching up timestamps.
You can check the TSSS jobs and status with TSSS URL API:
https://docs.tibco.com/pub/sf_statsvcs/11.4.5/doc/html/TIB_sf_statsvcs_11.4.5_urlapi/urlapi/topics/jobs.html
Here is an article on how to find the execution time and status of a TSSS job using TSSS SplusServer.log file:
https://support.tibco.com/s/article/How-to-find-the-execution-time-and-status-of-a-TSSS-job-using-the-TSSS-instance-s-SplusServer-log-file
Versions:All
Summary:
TIBCO Spotfire Statistics Services (TSSS) server could sometimes get strained when the server is overloaded with many jobs or when there are some large jobs being executed. You can check the status and execution time of the jobs with TSSS API job URL, together with analysis of Spotfire Web Player logs to identify which jobs are straining the server.
Details:
A TIBCO Spotfire Statistics Service (TSSS) server may sometimes be strained with memory and CPU fully utilized. This article describes how to track memory and CPU usage for each job executed in TIBCO Spotfire Statistics Services.
Resolution:
(1) If you use a JMX-compliant monitoring tool such as TIBCO Hawk or JConsole, you can monitor the Statistics Service (TSSS) Server’s health and status including memory and CPU usage, edit the server configurations, and manage the job queues of Spotfire Statistics Services, all remotely.
Here is a document on TSSS Remote monitoring and management with JMX, for your reference:
https://docs.tibco.com/pub/sf_statsvcs/11.4.5/doc/html/TIB_sf_statsvcs_11.4.5_installation/installation/topics/remote_monitoring_and_management_with_jmx.html
----------------
Using remote management and monitoring through JMX, you can perform the following tasks:
Restart Manager or Worker nodes.
View and edit the server configuration.
Perform job and package management.
Manage nodes in a cluster
----------------
Such JMX monitoring tools could help you monitor the resource usage of TSSS service at all times and manage the running jobs when the resource usage is high.
(2) However, JConsole could track memory usage of an individual job, but each TSSS job runs in a separate (new) JVM and JConsole needs to connect to each JVM to gather statistics.
So you'd need to have some way to connect to each job JVM and monitor it, which would be hard to do and use it systematically.
CPU and memory usage for jobs executed in TSSS server are not logged specifically. Instead, the execution time it takes for TSSS service to run the jobs is however logged.
Reviewing the job history and job status with TSSS jobs API URL (http://<TSSSserver>:<port>/<ServiceName>/api/v8/jobs), can often be a good indicator of what is causing the system to slow down, especially if you know WHEN the system is being strained and can match that up to the job history.
Often (but not always) jobs that are using a lot of resources naturally take longer to run, so you can also just look for abnormally long running jobs, or jobs that seem to slow other jobs running at the same time down.
Even better, if you have job failures or jobs that are interrupted, that's a good indication from the job history that something's causing problems.
Then you do have to match those up to the Spotfire Web Player logs to figure out which user / data function is causing that, but that's just matching up timestamps.
You can check the TSSS jobs and status with TSSS URL API:
https://docs.tibco.com/pub/sf_statsvcs/11.4.5/doc/html/TIB_sf_statsvcs_11.4.5_urlapi/urlapi/topics/jobs.html
Here is an article on how to find the execution time and status of a TSSS job using TSSS SplusServer.log file:
https://support.tibco.com/s/article/How-to-find-the-execution-time-and-status-of-a-TSSS-job-using-the-TSSS-instance-s-SplusServer-log-file
Comments
0 comments
Article is closed for comments.