Slow ArcGIS Server Environment Issues

[JordanMiller4]

We have virtual machine that's being hosted on a server at our second office 2 hours away. The OS of that VM is Windows Server 2012 R2. The machine has the following programs install: ArcGIS Server | Portal | web adapters | Data Store (Not being used at the moment) | SQL 2012 for the database. The images below show more details.

Problem - When we're connecting to the database through ArcMap or ArcPro and create a child version under the Default the performance drops drastically to the point that the actual programs (ArcMap/ArcPro) stop responding and crash. I'll provide our server specs below. Please provide troubleshooting ideas below and I will do my best to stay updated with everyone on here.

Physical Server 

VM Host - Hyper-V

VM Machine specs w/ sql gdb

VM - Machine task manager

[ThomasColson]

Based on the number of ArcSOC's running, I'm assuming you're spawning more than 1 or 2 feature services. ArcGIS Server and SQL are memory HOGS. I was in your boat a few years ago, and learned through painful experience to isolate each application of the GIS "stack" on it's own VM, and set the Hyper-V memory settings accordingly. There is no way you're going to get the performance you're expecting with SQL and GIS SVR on the same machine, with that many service instances (yes, even just 28). Trust me....kick SQL to its own VM, and a physically separate VHD if you can. If SQL and the GIS SVR Data store share a VHD, you're going to have the same performance problems. I went further and put the SQL log and temp files on physically unique VHD's, and saw further improvement. Another option would be to move your entire environment to a high-speed SAN...e.g. a Dual NIC QNAP with RAID 10. You're further limited by what appears to be 12 cores, not sure how your hyperv is set up, but Portal, SVR, and SQL (with 49 users!), you're really pushing the edge of the envelope. Just for giggles what happens when you turn off Portal in Services? 

Would love to see how you fix this, but, the best recommendation you're going to get is to call Tech Support. I ended up getting ESRI tech support on the phone with the data center folks, and that's how we got it fixed.....

[MichaelMiller2]

I echo Thomas Colson‌ comments.  Isolation of applications is key. As well as increasing the number of cores(processor) and memory per machine will do wonders.

[RandallWilliams]

I'll take a different tack. When working with Desktop against an enterprise geodatabase, the communication is quite chatty. In addition to the suggestions above, I'd also look a this from a bandwidth perspective. 

Here's a quick test: Do users in your remote office have trouble performing this same workflow when connected to this database? If not, then the issue is likely related to the network. 

In this case, can you create a child replica from the parent, work locally from the replica, then when you're done reconcile and post to the parent?