1 of 1 people found this helpful
We use AOAG for LDMS - we do not have any issues with performance at all.
Have you performed a db health check on their AOAG system?
Have you tried connecting directly to the db server that is currently the "primary" instead of using the AG listener? This should by pass the AG part and utilize it as if it was hosted on a dedicated server.
Hope this helps,
Thanks for the info! That helps a lot. I'll go back to my client and see which he is connecting to. If he is connecting to a "listener," I'll have them test on a primary and see if performance changes. They have a DBA in-house as well, so I'll recommend a health check on their servers.
I'll share an update with the results.
LDSD Support Engineer
Quick update for anyone reading this - This ended up being a bug with VMWare, which is what the customer is using for their server environment. These performance issues were not caused by Service Desk, and has been seen with other applications in their environment since.
Do you know what the bug was in VMware? We have had similar issues and our VM team has made several "tweaks" and things are running better, but not what they were before moving to the SQL cluster. Hoping I can get details on the VMware bug to pass this on to my VM team to investigate.
I followed up with the customer to get some additional information. The performance issues seen were related to VMWARE 6 - Update 1 on Windows Server 2012 R2 servers. Disabling RSC on the Servers, via 2 powershell commands was necessary. This is supposedly fixed in Update 2.
I hope that helps.
This was the issue in our environment. The VMware link regarding the bug is here: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2129176
We changed the NIC type on our SQL AO servers to the N1000E in vCenter, and the performance issues were resolved. Thanks to Peter, and the customer who reported this, for the information so that we could resolve this issue so quickly.