Comment on page
Cluster
These metrics provide insight into the performance of the cluster running your job.
The following metrics will help you diagnose performance issues with the cluster upon which your job is running, and guide you in troubleshooting any issues.
Metric
See All Events (SQL Syntax)
Troubleshooting
Run the following SQL command in a query window in Upsolver, replacing <cluster_id> with the Id for your cluster. For additional columns, alter this statement and use
SELECT *. SELECT STRING_FORMAT('{0,number,#,###.##}%', utilization_percent * 100) AS utilization_percent, IF_ELSE(utilization_percent > 0.9, 'ERROR', IF_ELSE(utilization_percent > 0.7, 'WARNING', 'OK')) AS utilization_percent_severity
FROM system.monitoring.clusters
WHERE cluster_id = '<cluster_id>';
Consider increasing the server limit or splitting moving larger jobs to a separate compute cluster.
Metrics
See All Events (SQL Syntax)
Metric type | Informational |
About this metric | The number of job tasks pending execution in the cluster queue. |
Timeframe | Now |
The number of job tasks pending execution in the cluster queue, which represents the amount of work not currently being processed in the cluster because the cluster is at high utilization.
This number can be above 0 even if the Utilization Percent is below 100. This is because of the distribution of work between servers. It might be that work is allocated to a specific server, which is at 100% utilization, but the cluster itself is not at 100% utilization and there are other servers that have free slots, but they are not going to be doing this particular work, so the Tasks in Queue value might be greater than 0.
Upsolver will do re-balancing to ensure this doesn't continue over time. The Tasks in Queue value can be smaller than the number of Job executions currently in queue because the cluster only adds tasks to the queue in chunks, it doesn’t add all of the tasks. For example, if you want to replay 1,000,000 tasks, the number of tasks in Job executions currently in queue will show 1,000,000, but Tasks in Queue will only show the next chunk of work, e.g. 1,000. Therefore Tasks in Queue may only show a subset of the number of Job executions currently in queue tasks.
Run the following SQL command in a query window in Upsolver, replacing <cluster_id> with the Id for your cluster. For additional columns, alter this statement and use
SELECT *. SELECT STRING_FORMAT('{0,number,#,###}', tasks_in_queue) AS tasks_in_queue, 'OK' AS tasks_in_queue_severity
FROM system.monitoring.clusters
WHERE cluster_id = '<cluster_id>';
Metric
See All Events (SQL Tasks)
Metric type | Warning |
About this metric | The percentage of time that the server is doing garbage collection rather than working. |
Limits | Error when > 10% |
Timeframe | Now |
The percentage of time that the server is doing garbage collection rather than working should generally be under 10%. If this value is showing red and the cluster is not doing a lot of work or the cluster has crashes, it’s often indicative that you need bigger servers with more memory.
Run the following SQL command in a query window in Upsolver, replacing <cluster_id> with the Id for your cluster. For additional columns, alter this statement and use
SELECT *. SELECT STRING_FORMAT('{0,number,#,###.##}%', memory_load_percent * 100) AS memory_load_percent, IF_ELSE(memory_load_percent > 0.1, 'ERROR', 'OK') AS memory_load_percent_severity
FROM system.monitoring.clusters
WHERE cluster_id = '<cluster_id>';
Metric
See All Events (SQL Syntax)
Troubleshooting
Run the following SQL command in a query window in Upsolver, replacing <cluster_id> with the Id for your cluster. For additional columns, alter this statement and use
SELECT *. SELECT STRING_FORMAT('{0,number,#,###}', crashes) AS crashes, IF_ELSE(crashes > 0, 'ERROR', 'OK') AS crashes_severity
FROM system.monitoring.clusters
WHERE cluster_id = '<cluster_id>';
Typically crashes are due to memory issues when trying to load large lookup tables. Consider changing the cluster to a type with more RAM.
Metric
See All Events (SQL Syntax)
Troubleshooting
Metric type | Warning |
About this metric | The percent of bytes re-loaded into memory from disk. |
Limits | Error when > 200% Warn when > 30% |
Timeframe | Today (midnight UTC to now) |
The percent of bytes re-loaded into memory from disk. High values indicate more memory is required as many page faults will result in slow processing.
The metric represents how much extra work needs to be done in loading data because there is not enough memory on the server.
Each server has an in-memory cache, the Reload from disk percent is how many operations are served by the cache versus how many have expired from the cache, and need to be reloaded. Numbers above 0% are fine, but if this is significant and over 200%, the cluster is working too hard due to a lack of memory.
Run the following SQL command in a query window in Upsolver, replacing <cluster_id> with the Id for your cluster. For additional columns, alter this statement and use
SELECT *.SELECT STRING_FORMAT('{0,number,#,###.##}%', reload_from_disk_percent * 100) AS reload_from_disk_percent, IF_ELSE(reload_from_disk_percent > 2, 'ERROR', IF_ELSE(reload_from_disk_percent > 0.3, 'WARNING', 'OK')) AS reload_from_disk_percent_severity
FROM system.monitoring.clusters
WHERE cluster_id = '<cluster_id>';
Change the cluster to a type with more RAM.
Last modified 5mo ago