Skip to main content

Job Controls

Cancel Jobs​

  • In the running UI for your Job, there will be a Cancel button:

  • (For Admins only) To cancel any Job in your Holistics workspace:

    1. Go to Job Monitoring

    2. Cancel the target Job(s)

      • To cancel all Pending Jobs, click the Cancel Created Jobs on the top-right corner of the page
      • To cancel a specific Job, click the Cancel button on the right end of a Job entry

How cancellation of Running Jobs works

Some type of jobs can be cancelled while Running.

While cancelling a running job, Holistics will also try to cancel all running queries of that job in order to save your database server's resources.

Holistics uses a simple, yet effective mechanism to cancel job's running queries. We includes the job's id as a comment in every query sent to your database server, and uses this information to identify the specific process running the query. Afterwards, Holistics will send a specific query depending on DataSource type (e.g, pg_cancel_backend for PostgreSQL) to kill the identified process.

Automatically cancel unused Jobs​

Notice

This feature is currently in Beta!

In the Admin Settings page, Holistics offers the Unused Job Timeout setting that automatically cancel unused Jobs:

Demo

Explanation

  • Unused Jobs: Jobs that are not being used by any user's browser
    • For example: A user visits a Dashboard with 10 widgets and creates 10 Jobs, then closes their browser => Those 10 Jobs are unused.

Notes

  • This auto cancellation only applies to Jobs in these Job Queues:
    • Report
    • Embed
    • Adhoc Query
  • What if my users want to keep the Jobs running in the background (e.g. to warm up cache)?
    • Implicitly keeping the Jobs running makes it really hard to control the resources.
    • Thus, if it's really necessary, please advise your users to do these instead:

Disable Dashboard Auto-run​

Disable Dashboard Auto-run also help avoid spawning unnecessary Jobs.

info

Please refer to Disable Dashboard Auto-run.

Increase your default slots for specific Job Queues​

This approach cannot be done from your side since this action will require our support engineer to adjust the queue size.

If you think that your current default slot (2 concurrent jobs for data transforms for example) is not enough for your operation, please contact us via [email protected] and we will process your request.

References:

Limit the Query Timeout of your Database Connection​

Having a limit on the Query Timeout would help prevent slow queries from occupying the Job Queue for too long and block the other Jobs.

Please refer to this documentation to configure the Query Timeout of your Database Connection.

Example Scenario

Let's say you have a Dashboard of 25 Reports, each Report takes 1 second to run. By default, the Report Job Queue has 10 slots.

Therefore, when you open the Dashboard (and the cache is not available):

  1. At t = 0, 10 Reports will be executed first in parallel.
  2. At t = 1 second, the first 10 Reports will have finished, so the next 10 Reports will be executed in parallel.
  3. At t = 2 seconds, the second 10 Reports will have finished, so the last 5 Reports will be executed next in parallel.
  4. At t = 3 seconds, the last 5 Report will have finished.

-> It takes 3 seconds in total to run your whole Dashboard.

Then, an Analyst makes some modifications to the first 10 Reports, causing them to take 5 seconds to run. Without any Query Timeout, those first 10 Reports will occupy the whole Job Queue for 10 second and delay the other Reports.

As the result:

  • It now takes 7 seconds in total to run your whole Dashboard
  • It takes 6 seconds to see the result of Report 11, even when Report 11 takes only 1 second to run

With a Query Timeout of 1 second, the first 10 Reports will be terminated after 1 second, freeing the Job Workers in the Job Queue for the other Reports:

Thus, the Query Timeout configuration can be handy for you to control the Job Queue.

Notes

Query Timeout can also help protect your Database resources from too much load.

Notes

If a query keeps timing-out, it is best to optimize the query or quarantine it (e.g. by moving it to your personal workspace or deleting it) to avoid unnecessary load whenever opening the Report using that query.

Limit Number of Report Jobs Run Per User​

Since the max concurrent jobs are being capped per queue, when a user A purposely or accidentally farms multiple jobs, these jobs quickly take up all the available slots in the queue, causing other users unable to use the system.

To prevent this from happening, admins can set a limit on how many report jobs each user can run concurrently. You can find this setting in the Admin Settings page.

Disclaimer

This Limit setting is most suitable when you have many Users using many different Reports.
Otherwise, Job De-duplication may apply and actually result in your Users waiting longer. See explanation below.

How Report-Jobs-Per-User-Limit works with Job De-duplication

When multiple Users use the same Reports, their Jobs would be de-duped and only the first Jobs are executed.

So for example, if the Report-Jobs-Per-User-Limit is 5, then this can happen:

  1. User A visits Dashboard X with 10 widgets -> create 10 Report Jobs (ID 1 to 10).
    • Since the Limit is 5, only the first 5 Jobs (ID 1 to 5) will be Running, and the latter 5 (ID 6 to 10) will be Pending.
  2. User B visits Dashboard X -> create 10 new Report Jobs (ID 11 to 20).
  3. The system detects that the Jobs with ID 11 to 20 are the same with Jobs ID 1 to 10.
    • -> It de-dups those Jobs and hence User B would also use the same 10 Jobs of User A (ID 1 to 10).
  4. -> Although there are 2 concurrent Users, there are only 5 Report Jobs (ID 1 to 5) running at a time.
Let us know what you think about this document :)