Checking load of smart groups on server?

[tkessler]

I have a hosted JSS solution and I cannot currently log in to check process statistics like CPU load, but have noticed at times my JSS pauses at updating clients (ie, sending push notices), and am curious how many smart groups it would take to cause any noticeable load on the server? I've currently got about 100 smart groups configured.

[jjones]

Not a direct answer to your issue, but do you happen to have multiple nested smart groups? We have a few and have been told that they can cause a heavy impact on performance if it's accessing different tables per query.

The only part you can really watch in JSS for load is the memory usage under Management settings --> JSS Information.

[cdenesha]

We are hosted and the memory usage is no longer available to us.

When I was concerned about a lot of load during a deployment, we asked our TAM to ask Online Services to monitor for a couple of days and they were able to report on the load for those two days.

chris

[lwindram]

I can offer some suggestions based on some recent struggles with smart groups, but I can't comment on whether the latency sending push notices is a symptom of excessive smart group related JSS load. My symptoms were confined to smart groups - they took an excessive amount of time to process changes and reported incorrect membership for several hours after any changes.

All smart groups are recalculated every time any computer submits inventory. You can run into problems if you combine a large number of smart groups, a large number of devices, and frequent inventory updates. The only ways to manage this are to a.) reduce the number/complexity of smart groups or b.) reduce the frequency of inventory collection. According to JAMF, scaling hardware is not an effective means to remediate this issue.

It is worth knowing that smart groups and saved inventory searches have a very similar underlying architecture. Any saved inventory searches are also recalculated each time a computer submits inventory. As @jjones mentioned, nested smart groups can significantly exacerbate this recalculation latency.

In my environment reducing the number of smart groups was not an option, so I focused on reducing the rates of inventory collection. Reducing the client check-in frequency helped significantly; I went from an every 15 trigger to an every 60 minutes trigger. For most of my policies this is an adequate frequency.

Occasionally I need to deploy something more quickly. For those instances I utilize a modified version of the jamf LaunchDaemon in conjunction with a custom trigger. All of my computers have an LD that cycles every five minutes and runs

jamf policy -trigger every5

I set the urgent policies to run on a custom trigger called every5.

Hopefully this is helpful.

All of this hasn't been an ideal solution as I still experience occasional smart group errors. To keep everything in line, I have had to incorporate additional smart groups to check for and retract incorrectly deployed policies. Doubling up on the smart groups has exacerbated the calculation problems, but also resolves the consequences of those errors.

[cdenesha]

Your post is very helpful @lwindram.

Thank you also for your detail. I have been under the impression that saved searches were only calculated on demand, and now I see that "The results of a saved search are updated each time mobile devices contact the JSS and meet or fail to meet the specified search criteria." I have been concerned about the number of Smart Groups I create, but not the number of saved searches. I also opened up Advanced Search permissions to all the other techs, junior level included. This is putting load on my system?!?!?

[cdenesha]

The quote in my previous post came from the Admin Guide.

I set up a blank DB in a local VM. When smart groups are updated it populates the new data into _membership tables. This is not happening for saved searches.

I asked my TAM to triple check on this and got this response: "Smart group stored data will be in the mobile_device/computer_group_membership table. Advanced searches are volatile data generated every time the search button is pressed."