Discovery schedules getting stuck

[rinkus597]

Hello Experts,

We have been facing this issue for some time where discovery schedules are getting stuck in active state for a while and eventually get cancelled, found that in sys_trigger table ready state ASYNC:Discovery sensors count increase whenever schedules get stuck. I suspect this increase in ready state sensor count is the cause of large number of schedule cancellation in this case, but unable to understand why the ready state ASYNC:Discovery sensor count increases all of a sudden.

Anyone has faced similar issue where schedules get stuck and get cancelled?

Thanks in advance!

[Rahul Priyadars]

how big and IPS this schedule is covering

I see KB around this

• https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0610485
• https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0727126

Regards

RP

[rinkus597]

Hi Rahul,

Thanks for the KB articles, the schedules are mix  up of small subnets(/28,/30), large subnets(/24,/16) and are configured to run daily(as after discovery). This high number of schedules cancellation behavior is seen twice a week. 

Thanks

[Kiran_T]

There are couple of things to check

1.The Mid servers utilization for the schedules which are stuck , id you observe any spike in the cpu ?

2.Are the Mid servers being used by any other process in the instance(like- orchestrations, SM, etc)

3.There could be a situation where the Mi server might be Out of Memory ,increase the Java Heap memory configuration on the Mid server  for a better performance .

https://docs.servicenow.com/en-US/bundle/utah-servicenow-platform/page/product/mid-server/task/t_MID...

[rinkus597]

Hi Kiran,

1.The Mid servers utilization for the schedules which are stuck , id you observe any spike in the cpu ? Most of these schedules are configured with MID server clusters, CPU is stable during discovery.

2.Are the Mid servers being used by any other process in the instance(like- orchestrations, SM, etc)? These are dedicated MID servers for discovery.

Thanks,

Rinku