The first agent of any assigned configuration to check into any coordinator and request a new copy of its configuration, would kick-off the stored procedure as would normally occur.
When any subsequent agents using the same configuration connect to that same coordinator and request a new copy of their configuration, the coordinator would compare version number of the cached copy to the version number of the configuration in the database. If the numbers match, the coordinator would simply return the cached copy of the configuration to the agent instead of running the dbo.usp_AgentConfiguration_Read stored procedure again.
This has the potential to considerably reduce the CPU utilization overhead on the SQL server, which was essentially what was causing this issue. (The SQL server got busy, then none of the agents got their configuration, which in-turn meant that nothing was being protected and would also trigger another attempt to get the configuration). In practical terms, if you have 1000 agents using the same configuration, you would only have to invoke that stored procedure once per coordinator (instead of the 1000 times that currently happens). This would also allow coordinators to continue to process agent configuration requests for any configurations that are already cached, even if the SQL server is busy. The SP is still resource intensive, but running it far fewer times should allow events like this in the future to be far less impactful.
Enhancement request 355074 – has been submitted to change the design approach in the future.
This aims to improve the performance of dbo.usp_AgentConfiguration_Read timing out in a large customer environment by caching in coordinator.
Using this approach to cache the agent configurations on the coordinator(s) , it will significantly reduce the number of times that the resource intensive dbo.usp_AgentConfiguration_Read stored procedure would get called on the SQL database.
As this is a complex code change, involving a change in the approach to agents/coordinators and SQL Server behavior, it will require significant testing before being implemented.
It is currently planned to be included in the next release of Change Auditor.
A release date time for delivery in still being estimated however it is likely that the next release of Change Auditor will be available in Q3 ( Aug, Sep, Oct) 2022.
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center