What the foloowing messages in the stadlog usually mean?
06/18 13:00:26.87 serverxxx. animator_nxd 8576 ERROR animator_nxd.c 2471 Recurring animator ANI:266286311 (cr:4169073) for atev:76944623 missed 1 firings, the first at 06/18/2020 13:00:00
06/18 13:01:51.07 serverxxx. domsrvr 10912 SIGNIFICANT top_ob.c 4483 Contact 00 is holding lock for atev:72142514 used by animator ANI:266286288 (cr:3782470) for atev:72142514; retrying in 25 seconds
Release : 17.x
Component : SERVICE DESK MANAGER
These message is mostly related to performance / tuning.
Some suggestions to handle this scenario:
1) Create a dedicated domsrvr for the Animator process.
configure a dedicated domsrvr for soap web service advanced availability
Create a dedicated domsrvr for the Animator Process in Conventional mode
2) Upgrade your system to the latest release
This is not just to get to a supported release of CA ITSM (SDM), but because you are long overdue for a refresh of your environment. Hardware, software and most likely your business use case have entirely moved on for the system as first deployed. I can guess fairly safely that this system needs a good tune-up and refresh.
Some points that you may want to look at:
* Hardware refresh - more CPU and memory, and possibly extra boxes.
* Additional domsrvr/webengine pairs. Roughly one per 150 users or per CPU on a server.
* Dedicated domsrvr for Animator, and any other process that needs it.
* Add on secondary servers if in Conventional Configuration, or expand to Advanced Availability.
* Use new access points that bypass web clients, such as the mobile interface and Service Point.
* Tune Tomcat memory setting, add extra database agents (MAX_DBAGENT), turn off MONITOR_JOINS.
3) Perform a rough performance review of the current system.
How may we identify performance issues in Service Desk and what type of data is helpful to Support to resolve these issues?
I wouldn't go overboard on this, but it would not hurt to review the stdlogs and performance tune the system "as is." (Briefly).
Tell-tale signs of stress can be seen by searching for "milliseconds" in the stdlogs and looking for common issues. A well running system won't have many of these messages. An overloaded system will have a lot. And it is best to address the root cause of the overload. However there *may* be something specific that is causing the Animator to overload. In practice though, you're unlikely to be able to troubleshoot to that level of detail on your own, and there is limited advice that can be given that does not boil down to "upgrade and tune."