Performance Issues with Long-Running Scheduled Jobs - sam-generate data for software lifecycle

[Eitan_B]

Hello everyone,

I have encountered an issue with the "sam-generate data for software lifecycle" scheduled job in our ServiceNow instance. I noticed that there are 19 scheduled jobs with the same name still in progress, spanning from two years ago to the present day. This information was found in the samp_job_log table.

Could the presence of these long-running jobs be causing the current "sam-generate data for software lifecycle" job to take longer than usual to complete?

Has anyone experienced similar issues or have insights on how to resolve this?

Any advice or suggestions would be greatly appreciated.

Thank you!

[dreinhardt]

Hi @Eitan_B,

of course, this could be a reason. Please perform the following steps:

1. Change the status for all running jobs from "In Progress" to "Failed" (Example Script by ChatGTP)

// Create a GlideRecord object for the samp_job_log table
var jobLogGR = new GlideRecord('samp_job_log');

// Add query conditions
jobLogGR.addQuery('job_name', 'SAM - Generate Data For Software Lifecycle Report');
jobLogGR.addQuery('status', 'In Progress');

// Query the table
jobLogGR.query();

// Iterate through the records and update the status
while (jobLogGR.next()) {
    jobLogGR.status = 'Failed';
    jobLogGR.update();
}

// Log completion (optional)
gs.log('Updated all jobs with the name "SAM - Generate Data For Software Lifecycle Report" from "in progress" to "failed".');

2. Navigate to All > Active Transactions (All Nodes) and verify no thread for the job is still active. If so, please kill it

3. Execute the scheduled job "SAM - Generate Data For Software Lifecycle Report" (All > System Scheduler > Scheduled Jobs > Scheduled Jobs")

4. Verify the execution status, should be completed after a few minutes

If 4. failed, please raise a ServiceNow support case.

Best, Dennis

[Eitan_B · Accepted solution]

I got an answer from another engineer.
The jobs marked as "in progress" in the samp_job_log table are not actually still running. For example, a job marked as "in progress" was completed after being canceled, indicating it was not finished and thus marked incorrectly in the database.
this answers my original question...I thought that the 19 jobs were still running effecting the perfromance of the actual job sam-generate data for software lifecycle that runs daily.