Jamf Pro Performance Issues on-premise

[user-BqBTAgwquG]

Just wondering whether anyone else has seen any performance issues on an on-premise instance of Jamf Pro running on Windows Server 2019?

We recently upgraded to v10.37.2 but since ~10.34.2 we’ve seen a lot of unresponsiveness at various points throughout the day, such as no response when trying to log in, or lots of white space and blue circles when moving around the web UI, say from Policies to Configuration Profiles for example. After 10-15 minutes of unresponsiveness, everything is fine until it happens again. When this happens, our platform guys report “100% CPU caused by Apache Commons Daemon Service Runner”. There's nothing conclusive in the Jamf logs.

The VM has 4 x 2.40GHz CPUs and has 16GBs of RAM, 8GB of which is allocated to Tomcat. Java and MySQL is fully up to date. Our (internet facing) DP is also hosted on the same server.

I have a case open with Jamf who have logged in and run various MySQL commands, but they’re not really sure what is going on. Therefore I’d really appreciate any insight!

[isradame]

We had the same problem a year ago. Our issue was a bug in Apache Tomcat. For version 10.36 we had to upgrade MySQL to version 8.0.28. This is what we are using and is working great on Windows 2019 with the same specs as yours.

Amazon Corretto OpenJava JDK 11.0.14.10

MySQL 8.0.28 - this is required for 10.36

Tomcat 8.5.76

[user-BqBTAgwquG]

Thanks - we are running exactly those versions of Java, Tomcat and MySQL.

[user-BqBTAgwquG]

So my Windows guys went through everything with me this morning and it looks as though MySQL is blowing up the CPU. We even threw 4 more cores at it but still we see issues.

Can I therefore assume there is some sort of corruption in the database? Are there any commands that you would recommend to optimise things?

[Discher]

I don't have a great answer, but we are on prem, and I have seen our JSS response time slow down on occasion.  A few things I've done is increase the frequency of Log Flushing to 1 week, so there isn't a lot of extra garbage.  We were also running a recon on our entire fleet daily(!) which wasn't necessary.  mySQL should be allocated 50-70% of the system memory... if you are running Tomcat on the same server, it should be 50-70% of the memory remaining after Tomcat.  You have 16GB, 8GB seems high for Tomcat, you could try lowering that to 4GB, and maybe give 10GB to SQL.  Double check in the Jamf Pro Server Tools, that your values are correct for Tomcat, SQL Key buffer size, and that File per table is checked.  Good luck!

[askjason]

We are having the exact same issue. I might be wrong, but I think it all happened when we upgraded to Win 2022. We are on MySQL 8.0.19. I am going to try to upgrade mysql to the latest version and see if that fixes the issue. 

[askjason]

I fixed my issue with the help of JAMF Support. I upgraded mysql from 8.0.19 to 8.0.29. But what I really think fixed it was when I deleted some old extended attributes. In particular one we had for Sophos definitions. We switched AV products a year ago, but I had never removed that attribute. I am not sure why that would fix mysql, but now mysql hardly ever goes above 5% CPU utilization. 

[BCPeteo]

We are seeing the same issue here with Jamf pro 10.41 Its even worse with 10.42. (we are on windows server 2016)

Right now Jamf is saying they do not know why it is happening but recommending we try the database on linux.

Still going back and forth with them.

[deramirez]

Hi @user-BqBTAgwquG , did you ever resolved this issue?

We are at a lost. We noticed this issue and found some old configuration profiles causing a slow down when they would fail. We cleared those up, but the issue persists.

We also upgraded MSSQL and no luck.

We are exploring the idea of separating our Instance of Jamf (service) and MSSQL as they are hosted in the same server box.

[deramirez]

Forgot to mention that we have talked with jamf support, but they just tell us to cleanup our db. They provide the commands. The issue is cleared for a few minutes, but returns not long after.

[deramirez]

mySQL not MSSQL*