One of the functions of the ServiceNow platform is the ability to create a scheduled job to run at a specified point in the future. Scheduled jobs can be used for out-of-box maintenance tasks or a custom code that you have implemented to perform a specific function on a given schedule.
First things first, all scheduled jobs are stored in the sys_trigger table (scheduled reports are stored in sysauto_report).
Each JVM (application node) has a scheduler manager thread that is constantly checking to see whether there are any scheduled jobs that need to be run by this node. This is determined by the 'Next run time' being equal to or earlier than 'now.'
The Scheduler Manager
There is a scheduler manager thread running on each node
- Check sys_cluster_state - is this node configured to take 'any' or only 'specified' scheduled jobs
- Check sys_trigger for any job which is past his 'Next Run' time and is in a 'Ready' state
- Depending on how the node is configured, pick up the job and move it to the scheduler queue
If a node is in the passive datacenter of the High Availability pair, we don't want scheduled jobs to be executed. The latency between the application node in the passive datacenter and the database in the active datacenter is too high and the processing of any job would take far too long.
To prevent this from happening, nodes in the passive datacenter have their schedulers set to "specified".
The scheduler manager thread will only pick up jobs that are directly assigned to his System ID, or any job if his schedulers are set to "any".
Most people think that a scheduled job would execute exactly at the 'Next run time'. There is however, a little known field which users typically do not display on the form or list views of sys_trigger: the "max_drift" setting.
Using the max_drift setting when creating a scheduled job
Using round numbers like top of the hour, quarter past the hour, and half past the hour, will make scheduling jobs simple and easy to keep organized. When an interval or repeat based scheduled job begins to be processed, the next run time is calculated. The max_drift setting gives the system a window of time around what the admin has configured, to avoid having everything execute at the exact same time. For the most part, you won't even realize this is going on as it all happens on the back end.
** Note: This behavior does not apply to Scheduled Reports. These will execute at the specified time. **
Maintenance Tasks
There are a couple of maintenance tasks which you may want to ensure start at a specific time, preferably during your least busy time. Most notable of these are the Zing maintenance tasks, particularly on releases earlier than Calgary.
Zing maintenance tasks in the following sequence:
- TS Index Reaper - tidies up obsolete text search indexes (document was either updated or deleted)
- TS Index Stats - Runs statistics against Zing usage, generates new auto-stop words
- TS Search Stats - Runs statistics against Zing usage
By making sure maintenance tasks happen during off-peak usage hours, you can limit impacting performance. Another common job which we really want to know when it's going to fire is the "Upgrade" job. Part of ensuring an upgrade starts when you want is setting a low max_drift setting on the "Upgrade" scheduled job. I'll talk more about the upgrade process in my next blog post.
Update: 24 November 2014
It has been pointed out that any automation or scheduled job which is created using the wizard shown in the screenshot at the top of this post would have a primary record in the sysauto table. If the job is active, a sys_trigger entry is automagically created for scheduling. So far so good. It seems that sys_trigger records which are related to a sysauto record are in fact locked down, so you can not adjust the max_drift value for these entries.
Any stand alone sys_trigger records (such as the Zing and upgrade maintenance jobs mentioned in the post) can have their max_drift value adjusted. Hopefully this is helpful and apologies for any confusion caused.
Tables which extend sysauto
- scheduled_data_import
- sysauto_custom_chart
- sysauto_report
- sysauto_template
- sysauto_script
2 Comments
