JAMF Pro Windows Server is spiking at 100% CPU utilisation constantly

We've been dealing with this for over a year now, ever since installing Jamf Pro 10.26 I believe it was.  Mysql.exe will peg the server to 100% CPU usage to the point where the server itself is barely usable even just to check logs and stuff. I worked with support off and on for a month or two and the only conclusion we could come to was too many devices for our single server, but still seems odd that it was fine until 10.26 suddenly.  I've tweaked the mySQL and Tomcat settings quite a bit after hours and hours of research and we've given the VM it runs on some more ram and CPU cores to get it somewhat okay now but we still have a very slow performance frequently and sometimes it grinds to a halt and we have no choice but to stop and restart right then and there, that and our settings are way beyond what support has recommended in the past.   So we restart frequently and I always check the new version release notes hoping to find something about performance issues being fixed.  

Also we've found that opening a second tab or more (such as opening multiple devices in new tabs) will completely halt everything for about 30 minutes or until we restart.  Haven't timed it exactly to see if it has something to do with the login session timing out.  That has also been somewhat annoying as there are times when it's just second nature to open stuff in separate tabs.

Dam I really hope this gets resolved in a future update! Ours is barely useable as is...how much RAM and CPU cores have you assigned to get it to a functional state if you don't mind me asking?

HI, i also would be interesed in the amount of RAM and CPU cores / there specs you are using.
I remember that in some of the presentations about load balancing etc. they more or less talked about it.
Most of the time it was like 1 instance behind the Load balancer per 1000 up to 3000 devices.
Or as an alternative just giving the Instance more power until the drive will be the bottleneck xD

Currently we're at 28gb of ram and 6 CPU cores.  Originally (probably way back to the beginning of using a Windows server instead of an Xserve) we were at 2 cores and the VM was set to just adjust ram dynamically to what was needed (usually settled around 12gb total) when we started having the 100% cpu usage issue.  We added 2 cores first and set it to a dedicated 18 or 20gb of ram to see if that helped, which it seemed to.  Then recently went up to 28gb/6 cores.  Since we've started upping the server config, our Tomcat settings are 2gb min and 12gb max for ram (seems to use all of it no matter what it's set to, or else that's our bottleneck right there), and threadpool is 752.  Now our mySQL settings are up to 512mb max packet size, 301 max connections, 256mb key buffer, and 8gb buffer pool size.  I did a lot of research to come up with those numbers as far as what is too little/default/not enough for a large number of devices on 1 server, what formulas to use to calculate what they should be, etc.  We have 5150+ devices on one server, which is waaayy too many for one but these settings and "hardware" upgrades have helped quite a bit.  Originally we didn't have as many devices on this original configuration of a single server but we've since gone basically 1:1 with devices since and have added a lot more.  I wouldn't recommend these settings to anyone though, they could be completely way over the top.  We do still get the 100% cpu usage probably once a week or more, depending on how much activity there is, but that didn't used to happen with ~5000 devices on one server with 2 cpu cores/~12gb of ram until a little over a year ago.  What really doesn't make sense is when mySQL is pushing the server to 99-100% CPU, I can run a show full process list command and theres nothing going on during that.

Currently 16 cores, 32GB RAM. Approx 50k devices. Load is high at times, so we might bump it to 32 cores soon. But yes, JAMF code is quite inefficient so you need lots of horsepower to run it. For those that are more DB oriented, check the queries that JAMF does, and you will see that the MySQL query optimizer will often opt to use a full table scan even if there are indexes that can be used. If we execute the same query with FORCE INDEX, they complete at a fraction of the time compared when a full table scan is used. But this might be more of a pointer to the JAMF devs..

But to answer the original question, in general there's not so much you can do if you have enough I/O. Just ensure that MySQL is allowed to use approx 75% of the available RAM, that the disk system can handle the load, and you should be good to go. :)

When you say MySQL is allowed ~75% of ram you mean the buffer pool size, correct?

We just updated to 10.41, seems like we're constantly hitting 100% CPU and crawling server speeds now.  Wonderful.

We had this problem and after lots of back and forth with support we found the issue.  Here's a copy of the email with the solution so you can reference it when you contact their support, but I would NOT try to run the command without talking to Jamf support since everyone's environment is different:

We see a lot of Apple School Manager entries in our "show processlist;" command for the database that always seem to be there.  In an effort to stop that, thinking that was the issue, we've disabled most of the Apple School Manager stuff as we don't do managed Apple ID's or anything.  I will open a ticket with them and see if that's our solution as well.

Just ran the DELETE command after talking with support, they didn't have me change anything.  Our mysqld.exe process is the lowest I've ever seen it, that I can recall.  It's idling around .5-1%, previously 30% was doing pretty darn good.  The overall CPU usage on the server hovers around 10-20% now.  Hopefully this was solution!

Yes, on our 32GB DB server, we have the following config:

innodb_buffer_pool_size = 24G
innodb_file_per_table = ON

Ran the DELETE command also after contacting support.  They said I was affected by PI110051.  So maybe reference that number if you need to open a case.  The mysql.exe is now taking very little cpu compared to what it was using before.