9.4 jamfAgent hich CPU usage?

[colonelpanic]

Ever since upgrading to 9.4, we have seen the jamfAgent process on our clients slowly start to eat up more and more CPU. Eventually it reaches anywhere from 30-55% constantly. If we unload and reload the LaunchDaemon, the CPu usage returns to normal for a little while, but eventually it will slowly crawl back up to 30-50% CPU.

I have an active support case open, but I was wondering if anyone else had seen this behavior. Another thing that I found interesting is that running:

sudo fs_usage -w | grep "jamf"

showed that the jamfAgent process was constantly running sw_vers over and over again multiple times per second. Is anyone else seeing this behavior?

Thanks!

[colonelpanic]

It looks like we are going to have to live with that typo in the title... I can edit the body of the post but not the title.

[rderewianko]

Seems like i'm seeing the same thing, we weren't that worried about 40% usage as no users have reported it to be problematic. I'd be interested to find out what jamf has to say.

[rocklobster]

Same thing for me - approx 55% CPU usage and multiple calls to /usr/bin/sw_vers every second

[dpatzer]

We have reports of 50% - 55% CPU usage since the 9.4 upgrade.

[mm2270]

Interesting. jamfAgent pre 9.4 was the version that had the false "Not responding" issue under Mavericks. This was noted as fixed in the 9.4 release notes. I wonder if whatever changes they made regarding the jamfAgent are causing the high CPU utilization?
It would suck if so. I'd rather have the false not responding issue over high CPU utilization.

[colonelpanic]

Glad I'm not the only one! A defect has not yet been opened, but I'm sure that it will be now that I know I'm not the only one with the issue. Hopefully 9.41 is released quickly!

[colonelpanic]

Defect has been opened (D-007540)

[thoule]

Thank you for posting and followup @colonelpanic. We were just about to upgrade our systems to 9.4 and this would have been a big problem.

[dgreening]

Ack! I am not seeing this in my 9.4 test environment, and am going to be upgrading to Casper 9 in the coming days.

[mm2270]

Agreed. Thanks Colonel!

And, I hate to even bring this up because I know it initially sounds like bashing, but honestly, issues like this one are exactly why we need Feature Requests like this to be taken seriously: https://jamfnation.jamfsoftware.com/featureRequest.html?id=2345
For all the great stuff that came with 9.4, the last thing anyone wants is for the jamfAgent or any other jamf related processes to start eating up resources and causing performance problems on our managed devices. We get questioned constantly by our tech savvy users as to why they continuously see the jamfAgent showing up as "Not responding" in Activity Monitor on their Mavericks Macs. They see this when they start having any performance issues and immediately think its the agent that's at fault, when its not.
The fix for the false jamfAgent issue should really have been rolled into a specific 9.3<something> release, prior to 9.4 and the new features. That way maybe it would have been caught and addressed before all the great new items 9.4 brought. As is, issues like this can actually negate some of the good stuff, which is not what anyone wants, least of all JAMF.

I'll just state that I'm making an assumption here that could be incorrect. The assumption that the "fix" for the jamfAgent not responding issue is part of the cause here. It may turn out not to be that at all (in which case I'll gladly retract parts of my post here). But given the jamfAgent was updated to address that specific issue in 9.4, logic would seem to point to the fact that the updated version has a bug in it.
We'll just have to wait and see what JAMF has in the works to address this. Even if it turns out to be unrelated, I still see the need for bug fix only releases.

[tomt]

Extremely glad I saw this before going to 9.4 this weekend. It really seems like JAMF is putting too much emphasis on new features and not enough resources into getting things right. Maybe a case of growing too fast or just not enough developer talent in the Midwest? Either way there have been far too many defects in the latest releases for comfort.

Casper is still the best tool out there but lately it's been feeling like Quark did around versions 7.5 and 8. Still great but many annoying oversights in execution.

[dmueller]

While I'm not seeing the CPU hit beyond 4% I do see multiple instances of "posix_spawn /usr/bin/sw_vers" per second with "jamfAgent". Compared to the older client, this service is hyperactive. It also is showing in Activity Monitor as constantly using the CPU.

Thanks for posting this.

[cs-jeff]

We are having the *exact* same issue

[Malcolm]

Im not seeing much performance issues, although I found purging pending actions fixed up a lot of issues with peformance for us.

[tnielsen]

Also seeing this. This is really bad.

If I have to, I will remove the the agent from all clients until it's resolved.

[lkrasno]

Is it possible to redeploy the previous JAMFBinary and turn off updating from JSS ?

[denmoff]

I've also noticed this bug with 9.4. I wonder if it would make sense to script something that monitors the process and unload/reloads it when it reaches a certain threshold.

[dpertschi]

On lab install, I'm seeing this issue resolved with 9.5

From the release notes:
[D-007540] Fixed an issue that caused the jamf agent to incorrectly run a command multiple times per
second which caused the jamf agent to take up an excessive percentage of CPU.

[denmoff]

It appears to be resolved for me as well with 9.5. However, thanks to @colonelpanic, i'm now curious about what the agent is doing in the background with the command:
fs_usage -w | grep "jamf"
I see these three lines pop up every two or three seconds over and over. I don't have file vault turned on on this client.

/Library/Application Support/JAMF/run/file_vault_2_id.xml
/Library/Application Support/JAMF/file_vault_2_id.xml
/Library/Application Support/JAMF/file_vault_2_recovery_key.xml

[mm2270]

Those xml files are used to store the recovery key when FV2 is enabled on a Mac from a disk encryption configuration out of Casper and get picked up by an inventory collection process. Though I haven't seen the "run/file_vault_2_id.xml" file before. May be something new?

If FV2 hasn't been enabled on that Mac, that's very curious that it would be looking for those files, unless its done on purpose to scoop those up into the db as soon as they are spotted.