JSS Freeze up

What platform is your JSS on? We're on Windows. Once in awhile I see this (but not every day), and a reboot of JSS makes it go away for few months.

We have a Mac Mini server running OS X 10.8.5

The funny thing was this weekend I didn't have to touch it once and I was able to work from home without an issue.

I could imagine that the problem is related to one or more clients not being able to submit their inventory reports,
maybe due to the SQL max packet size being set too low in the JSS Database Utility.
Check your JAMFSoftwareServer.log for entries like

[ERROR] [JAMFPreparedStatement ] - SQLException from execute: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (2054502 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.

[WARN ] [NewProxyPreparedStatement] - Exception on close of inner statement. com.mysql.jdbc.PacketTooBigException: Packet for query is too large (2054507 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.

That would explain why it works through the weekend, when the client(s) is offline,
but crashed on monday morning when it probably tries to submit an inventory report and freezes up Tomcat in the process.

I would check the logs to get more info, but we experienced a similar issue on our Windows Server 2008 R2 JSS that was resolved by allocating additional memory to Tomcat: https://jamfnation.jamfsoftware.com/article.html?id=139 The freeze up occurred most often when we pushed out a user side Configuration Profile.

Is the java process running with extremely high cpu utilization? We've experienced a similar issue recently after upgrading out MySQL environment to 5.6 and then had to downgrade to 5.5 to re-stabilize. However, that was a MySQL issue initially for us and required us restarting the mysql service. When Tomcat became an issue, java usage was very high and required restarting which is why I'd take a look at any new additions/edits to your policies which are requiring a recon. Updating inventory too often when many clients are doing this at the same time can cause Tomcat to crash depending on your server overhead. I had to redistribute our load and create new tasks so that clients weren't updating inventory at the same time. You might want to re-randomize your everyX task to accomplish this along with checking the need for certain policies to update inventory when complete.

I too have seen this. Running Mac server 10.8.5, JSS 9.2. As @imperatives did, allocated additional memory seemed to do the trick. Not sure if it was the be all, end all, but the issue hasn't resurfaced yet.