Job service is not starting (initializing)

Dear All,

We have cc 60000 jobs in job queue, and when when restart the job service, it is not able to start, because it stucks on executing the QBM_PJobQueueInit stored procedure. This stored procedure didn't finish in 30 minutes. 

All the database metrix are goood meantime, no CPU and IO usage is happening. Any hint maybe how to speed up this?

Thank you,

Ervin

Parents
  • What is the version? Do you see errors in the system journal (table DialogJournal)? Creating a support ticket most probably is faster for these type of issues.

  • Hello Rodney,

    Thank you for your quick response.

    Version is 8.2.1.

    DialogJurnal didn't contain any information about this, also all other logs (JobService.log, StdioProcessor.log) were empty in this regards. When I validated against the database what is taking so much time, I have seen that the QBM_PJobQueueInit stored procedure is executing since minutes, and it bocks also other DBQueue related jobs, but meantime the CPU, memory and IO usage of DB was low. Could be theat something was wrong in tempdb side, but I didn't check. I run SQL Server profiler, and it showes that smaller SQL statetments are executed by this stored procesdure inisde, but they were also executed in milliseconds not in minutes. I suspected that some internal SQL qeury was taking too much time to execute because I had a lot of rows in JobQueue table, but SQL Profiler or SQL Activity Monitor was not showing such long running query. Also the CPU usage didn't say that something heavy is running there. Since it was production, I decided to delete some jobs which I was sure they will retriggerig again, and then restarted job service, and then is started processing. I didn't have too much time to analyze the issue further, because PROD was stopped becuase of this issue.

    When we tried to reproduce similar issue in DEV environment, then DEV was behaving proper way, it was executed in DEV, so I'm pretty sure that some bad database conditions were causing this in PROD, which we may probably (hopefully) never see again.

    Thank you for the response. I think I will not contact support, because if I cannot reproduce, than probably they will also not able to help with this too much, and I don't want to support more load because of this silly issue :)

Reply
  • Hello Rodney,

    Thank you for your quick response.

    Version is 8.2.1.

    DialogJurnal didn't contain any information about this, also all other logs (JobService.log, StdioProcessor.log) were empty in this regards. When I validated against the database what is taking so much time, I have seen that the QBM_PJobQueueInit stored procedure is executing since minutes, and it bocks also other DBQueue related jobs, but meantime the CPU, memory and IO usage of DB was low. Could be theat something was wrong in tempdb side, but I didn't check. I run SQL Server profiler, and it showes that smaller SQL statetments are executed by this stored procesdure inisde, but they were also executed in milliseconds not in minutes. I suspected that some internal SQL qeury was taking too much time to execute because I had a lot of rows in JobQueue table, but SQL Profiler or SQL Activity Monitor was not showing such long running query. Also the CPU usage didn't say that something heavy is running there. Since it was production, I decided to delete some jobs which I was sure they will retriggerig again, and then restarted job service, and then is started processing. I didn't have too much time to analyze the issue further, because PROD was stopped becuase of this issue.

    When we tried to reproduce similar issue in DEV environment, then DEV was behaving proper way, it was executed in DEV, so I'm pretty sure that some bad database conditions were causing this in PROD, which we may probably (hopefully) never see again.

    Thank you for the response. I think I will not contact support, because if I cannot reproduce, than probably they will also not able to help with this too much, and I don't want to support more load because of this silly issue :)

Children
No Data