Usually DS 6.9 will start a job immediately, even when the "allow task to be deferred up to 5 minutes" button is checked. During our busy season, (school startup), the engine starts to wait a full 5 minutes with a blank status before deciding to run the task. I do not know what this magical threashhold is but I believe it's either 100 or 200 scheduled jobs. Here's what I've observed with the database.
event Holds a list of every job in the console and stores the description and event_id for each
computer Holds a list of every computer that has an agent on it. Each is assigned a computer_id
event_scheule seems to have a list of all jobs that were scheduled as well as the job history of jobs that were run. Key columns are as follows.
- computer_id
- event_id (each job in DS has an event_ID associated with it)
- staus (the text that displays in the status column in the console
- start_time (when you told the job to run)
- broker_time (when the job actually started running)
- end_time (when the job finished)
- status_code (the return code of the job after it finishes)
- defer_mins (the option on the schedule tab for allowing the job to be delayed up to x minutes)
Using this query, I find we have about 212 jobs scheduled in the future
select computer.computer_name,event_id,event_schedule.status
from computer
left join event_schedule on computer.computer_id = event_schedule.computer_id
where event_schedule.status='' or event_schedule.status is NULL
When the status is Null that usually means that start_time is in the future. However, I've found several jobs in the past where both event_id and status are null. In these cases, the jobs do not show up in the console in the run history. I can't fathom how anything got into this table without an event_id and so consider it a glitch. If I remove all the jobs with a NULL event_ID, I'm down to 72 from 212.
For the jobs scheduled as "run now" that are waiting 5 minutes, the status shows up as blank. It then turns to "running script" when the 5 minutes elapses. This behavior occurs whether or not defer_mins is 5 or 0. DS doesn't seem to respect this setting.
We have three separate installs of DS and the one with only 150 events scheduled (comparable to the 212 number), it doesn't delay anything. Thus it seems to be counting these erroneous entries with NULL event_id's as for determining if it is overwhelmed.
So, it'd be nice to be able to crank this threshold higher to maybe 1000 and or cleanup these errant table rows to restore normal functionality, but I'm not sure what the impact would be. I'll consider backing up the database and giving it a try to see how it goes.