Hello Dheeraj,
First up - and this is to everyone - it is a good idea to sanitise any log data that is uploaded by CA Communities. Although you shouldn't come to any harm by doing so, I always think it is a good idea to replace items such as hostnames with text such as "MY_SERVER" for example.
Second, performance problems can be very difficult to troubleshoot remotely. We'll try our best here. But if you have a serious issue, it may be worth calling in a CA Business Partner or CA Services to run a healthcheck and at the same time, upgrade your system to a supported version such as ITSM 17.1. Someone onsite with the whole picture is in a much better position to provide advice on the whole solution, rather than troubleshooting spot issues as they arise.
Moving onto the troubleshooting.
Your starting point is to define the issue.
Your definition so far is "ITSM 14.1.03 is very slow while updating any Incident or Request tickets."
This calls out for clarification. For example:
* What does "very slow" mean? 30 seconds? Three minutes?
* What about other ticket types such as Change Orders, Problems or Issues?
* What about other parts of the system, such as Administration, Search, Configuration Items etc?
* Does this impact all users or only some?
* Does it occur at all times or only some times?
* When did this issue start? Has it been growing in impact or constant? Was it every working?
These are just examples, but a very good place to get a guide on defining the issue is here:
How to Identify Performance Problems in CA SDM - CA Service Management - 17.1 - CA Technologies Documentation
You should also define the environment.
* How many servers are there? You say "Conventional Configuration" which often implies more than one server (Primary server and Secondary servers), and yet only mention one SDM server. So is there only the one SDM server?
* Is CA PAM on its own server?
* How heavy is the CA PAM usage? Are there are a lot of Web Service calls? (If so, stand up a secondary for this purpose.)
* How many concurrent Analyst users do you have at peak? (Run pdm_webstat).
* Are all of the servers physical, and not virtual?
* How many domsrvr and webengine pairs do you have? (At 200 concurrent users, you should probably have a minimum of two pairs)
* Is your system Event heavy? (If so, dedicate a domsrvr to the Animator process.)
* Is there a test system? Does it see similar issues?
* Why is this system not on ITSM 17.1 and when will it be moving there?
* Is the environment showing any bottlenecks, such as a CPU core at maximum against an SDM process, memory reaching 2Gb, or a network or hard disk bottleneck? (I would guess that a CPU is maxed, based on the animator processes missing their firings and the long running messages in the stdlogs.)
* Are there any other CA products, like CA Catalog installed?
* How is the authentication done?
Look for common known issues.
See here to start:
CA SDM Performance Problems - Quick Checklist - CA Service Management - 17.1 - CA Technologies Documentation
And the Known issues for 14.1 for all point releases, starting with your version here:
Known Issues - 14.1.03 - CA Service Management - 14.1 - CA Technologies Documentation
Some things that spring to mind from what you've said so far.
1) SREL_BLOCKS_TIMEOUT is typically set to 30 to begin with, not 10. See:
CA SDM Performance Problems - Quick Checklist - CA Service Management - 17.1 - CA Technologies Documentation
and
The usage of NX_SREL_BLOCKS_TIMEOUT to improve Per - CA Knowledge
2) You've got 200 users probably pointing to one domsrvr. Add an additional domsrvr and webengine pair (or two) to spread the load, and leave the original domsrvr to handle the singleton processes, like Animator.
Rule of thumb is 150 - 300 users pointing to a domsrvr/webengine pair, but this is entirely dependent on load. A high Event system would have a lower number of users compared to a low Event system.
3) Is CA PAM on its own box? If not, it probably should be. Also, check the Web Services load. These will entries with the process name "sda" in the stdlog, but there are other ways to check. Start with CA PAM itself.
4) What is the volume of tickets and other data in the system? Both the absolute number already stored, and the daily/monthly generation rate. If these numbers are large, do you have Archive and Purge running to remove old/excess data?
5) When was this last working, and did it fail suddenly or slowly over time? The former might point to a sudden change, like a customisation being introduced. The latter might point to something like a growth in ticket data and usage.
6) Start testing a move to a certified ITSM 17.1 environment, and use this as a good opportunity to review your system setup and perform a health check. Now may be a good time to move to a primary/secondary or even an Advanced Availability configuration, for example. But only a familiarity with your environment and business needs would inform which are the better courses of action.
That should probably start your investigation. You don't have to go point-by-point through each part of the checklist, BUT you should check each part of the checklist and focus on the items that seem likeliest to be a cause.
Best case: Your system has simply grown over time, and needs additional resources such as extra domsrvr/webengine pairs, or a dedicated Web Services server.
Worst case: You've encountered a specific bug (possibly overlaid with the causes above) which needs specific troubleshooting techniques, such as log analysis, to identify.
And if in doubt, please just give us a little more information and we'll see if we can advise on those points.
Thanks, Kyle_R.