The past year and a half have been active for us in support in terms of dealing with MaxConcurrentApi issues. We’ve created a great deal of new documentation, updated existing documentation, successfully advocated some changes in product to help reduce the likelihood of these issues occurring and detect them easier when they do, and created diagnostics for support and scripting to quickly give a thumbs up or down on whether the issue is happening.
A lot of the work we have done is to help Microsoft support identify MaxConcurrentApi problems once you have already called us for help. However, our goal is to not have you need to call us in the first place.
To that end the System Center Operations Manager team has added a MaxConcurrentApi monitor into the latest Server Management Pack (version 6.0.7026.0). The monitor is based on the same code Microsoft support uses to detect the issue and will report the problem condition if and when it is seen on monitored computers.
You can download the latest Server Management Pack from this link.
Big thanks to the SCOM team for this valuable addition!
On Kevin Holman's TechNet blog blogs.technet.com/.../opsmgr-mp-update-new-base-os-mp-6-0-7026-0.aspx dated May 8, 2013, he states there is a bug in the new MP where the maxconcurrentapi detection monitor will generate false alerts. He recommends that it be disabled until at least the next update. Can someone confirm or deny this statement?
We are seeing this monitor, on a regular basis, alert us that the Maxconcurrentapi is depleted. I set it to 10 some time ago and most of the doc. from MS state this should be sufficient for most applications and that raising it above 10 could cause other bottlenecks with the system.
Has MS changed what they believe to be the best value for the Maxconcurrentapi?
Thanks Brian. This code producing some false positives is still being looked into. At this point it looks like the problem may be in the performance counter itself, but we are still investigating.
One thing to keep in mind is that there are many cases where this will alert and be a true failure which would otherwise go unreported. For those cases you can rule it in or out by looking at the _Total performance metric and seeing if the Semaphore Acquires counter is non-zero. If it is there and greater than zero there has been a timeout which gave a user a failure.
To answer your actual question, the MaxConcurrentApi value depends on load. In Windows Server 2008 R2 SP1 that max setting is 150, and in Server 2012 it can be up to 9999. The value you need is dependent on load in your environment, so 10 may work well for some, 2 (on member servers) for some, or higher for others. KB support.microsoft.com/.../2688798 can be used for some tuning as well. The rule (when the counter works well) does that tuning formula automatically.
When we know more about the MP concern I'll post on the http://blogs.technet.com/askds blog. Thanks for your patience everyone.