"deleted" process

[randolorian]

Anyone seeing lots of Console and CPU activity from the "deleted" process? I've had the GM running for about 12 hours and this process just never seems to rest.

UPDATE: Turns out this was a caused by iStat Menus. Updating to build 687 seemed to resolve it.

 

[simonmet]

My uptime is 1.75 hours and deleted has 0.27 CPU time (which unit?). You?

Not doing much here.

Edit: Unit is "core minutes". Therefore it's effectively 4 seconds of 100% CPU usage on my system in 1.75 hours. I'm not sure how hyper threading counts however.

 

[sddawson]

Anyone seeing lots of Console and CPU activity from the "deleted" process? I've had the GM running for about 12 hours and this process just never seems to rest.

I tried Sierra beta for a short while on a 12" Macbook. Deleted used a lot more cpu time than on El Capitan. From memory, it hovered around 4-5% all the time, whereas on El Capitan it barely ever uses any. I'd be hesitant to upgrade if this issue still exists, and since you're on GM it sounds like it does. I need all the battery life I can get!

 

[sddawson]

Sierra final definitely still has this problem. Constant "deleted" process messages in the log, and CPU that is usually around 2-3%. Some sample messages:

default 22:11:31.180908 +1000 deleted <private>: Successful Request
default 22:11:31.181030 +1000 deleted Connection to <private> was invalidated.
default 22:11:31.181052 +1000 deleted tearing down extension request for pid 5275
default 22:11:31.181124 +1000 deleted Connection to <private> was invalidated.
default 22:11:31.181279 +1000 deleted <private> took 0.078833 seconds, returned: <private>
default 22:11:31.181479 +1000 deleted <private> updateInfo: <private>
default 22:11:31.181607 +1000 deleted ENTRY, operation: CACHE_DELETE_PURGEABLE_OPERATION, serviceID: <private> info: <private>
default 22:11:31.181820 +1000 deleted updating cache for service: <private>, volume: <private>, amounts: <private>
default 22:11:31.181923 +1000 deleted updating service info amount: 117834861, serviceID: <private>, volume: <private>, urgency: 3 pushed: FALSE
default 22:11:31.182008 +1000 deleted sendNotification: FALSE
default 22:11:31.183050 +1000 deleted PurgeableSpace result: <private>
default 22:11:31.183312 +1000 deleted re-started persitence timer
default 22:11:31.183687 +1000 deleted SYNC purgeable op results: <private>

That "tearing down extension request for pid" happens over and over for the processes MailCacheDelete, iTunesCacheExtension, iBooksCacheDelete and CacheDeletExtension. Cant be helping battery life!

EDIT: I set up a new userid. All the above processes appear soon after login, but disappear soon after, and deleted is under control. On my own username, those processes stay forever and deleted is out of control. Now just have to figure out why!

 

[sddawson]

OK - more info...

On a fresh Sierra install, the processes MailCacheDelete, iTunesCacheExtension, iBooksCacheDelete and CacheDeleteExtension pop up at weird times. For instance, if you start Textedit they will start and run for a short time before disappearing (best way to see this is to have Activity Monitor running in its CPU tab and have "cache" in the search box). Also, if you start Preview and go to File, Open they appear the same way. Other apps they might appear when you start a save dialog. I have no idea what the processes do, and they even appear when you haven't logged into iCloud yet. However, they never hang around for long. In the Console log, you will see things like:

com.apple.appkit.xpc.openAndSavePanelService got a connection for: com.apple.cache_delete

Or:

Finder got a connection for: com.apple.cache_delete

Then a whole slew of messages start from the "deleted" process. But, as I said, the processes quit fairly quickly and no harm done. But, on my main machine with Sierra, the processes run non-stop and cause the CPU utilisation in the deleted process. So I started the process of finding out what was causing it. Well, turns out it's iStat Menus, if you have the Disks option checked. With it ticked, you get:

iStat Menus Status got a connection for: com.apple.cache_delete

Over and over, every 3 seconds. You have to untick and reboot to stop it. I'm going to contact the author and will post back...

 

[bernie-uk]

Hi

I had the same problem, which rendered the syslog and console useless, since they were filling up with 500 messages a second.

Launchd starts the agent com.apple.cache_delete which runs the process /System/Library/PrivateFrameworks/CacheDelete.framework/deleted. There are several cache extension that talk to deleted over XPC.

I created a new user as you mentioned above, and that does not have the problem.

I noticed there are some cache_delete setting files are in ~/Library/Caches/com.apple.cache_delete/

A solution that seems to work fine is move (or deleted) the ~/Library/Caches/ directory for the problem user.

I logged out of the problem account into another temp user, and with Terminal
$ sudo bash
$ cd /Users/<name>/Library
$ mv Caches Caches-tmp

Logged back in to original account and no more excessive logging.

Hope that helps.

Bernie

 

[sddawson]

What happens once you've rebooted? Can you see all those cache processes I mentioned running (in CPU tab of Activity Monitor with "cache" as a search term)? On the new user, do you see the processes running every time you start Textedit, but then quit after maybe 30 seconds? Are you running iStat Menus?

So many questions!

But wait, there's more! Do you know what the deal is with Console under Sierra? You can't see any messages earlier than when you start looking at the log, and the contents of the log are completely different to previous OS versions. This is when clicking the name of your Mac in the left column. And boy is it verbose! Never seems to settle at all...

 

[bernie-uk]

Yes I do have iStat Menus which is running fine.

There is ionodecache and TMCacheDelete which are owned by root and use no CPU.
AssetCacheLocatorService is always there for my user, with zero CPU
There is a deleted for each user logged in, which always present at zero CPU.

As you observed, if I launch TextEdit (from either account) the follow processes are launched for BOTH logged in users for a few seconds, then disappear
CacheDeleteExtension
IDECacheDeleteAppExtension
iBooksCacheDelete
iTunesCacheExtension
MailCacheDelete

I tried other stock Apple apps to see if they did the same, but nothing launched. After playing around I think it is any app that supports iCloud Documents is causes a quick cache clear on launch (eg Automator). Non-iCloud apps don't do this.

The cache directory should just contains temporary app data (generally created by URL access using NSURLSession or NSURLConnection) which can be thrown away. The apps will recreate the folders when they are launched again.

Must agree, with each release of OS X, syslog just seems to be getting more verbose with all the background cloud processes and sandbox checks. The new console app is also using up more CPU and sometime hangs. Still getting use to it, but did find the old console more responsive and easier to use.

The whole logging system has been redesigned by Apple to better cater for the more segmented multi-process approach to apps. Since there are a lot more helper processes that apps spawn, and inter-process communication with XPC, it is harder to debug, so Apple introduced a concept of activities (new icon on the toolbar), which allows you to see a more complete message trail generated between the app and helpers.

For more technical info you can have a look at WWDC 2016 video "721 - Unified Logging and Activity Tracing"
https://developer.apple.com/videos/play/wwdc2016/721/

 

[sddawson]

Thanks for that. Exactly the same as I see. After a reboot, do you see all those extra cache processes running continuously though, making the deleted process constantly consume CPU? That's what happens for me when I'm using iStat Menus to monitor disks. Or has your cache clearing stopped them running continuously for good?

I'll take a look at the video. Hoping there's some way to look at past messages. When you are trying to find out why something happened, starting Console after the event doesn't help at all!

 

[bernie-uk]

I didn't have the Disk option turned on for iStat Menus, but when I turn it on the cache processes appear, and more oddly, if I then turn it off, the cache processes DON'T disappear until I re-login. Seems a bit odd, so I will just leave that option off.

With Console, you can still view /var/log/system.log and it's compressed history, but agree, a lot of messages are just using ASL now and Console does not let you go that far back into the logs, which is a real pain with the volume of messages appearing.

 

[sddawson]

Yes, that's exactly the problem I was trying to debug, and what I detailed a few posts back. Causes Deleted to constantly consume CPU time. I have reported it to Bjango, and they have said they're looking into it. So what problem were you trying to overcome exactly when you first posted?

 

[randolorian]

Go to Bjango's Twitter page for a link to a new build (687). This stopped the spastic "deleted" process I was seeing in Sierra.

 

[bernie-uk]

I never had iStat Menu's Disk option on, but was getting a lot of deleted logging on my original user account, but not a test use (which also had iStat Menu running), so assumed it might be something in the old cache directory causing it. Unsure if there were multiple issues, just glad the logging has calmed down.

Thanks matamoris for the twitter info, the new build seems fine with the Disk menu on. They only increment the build number, the version number is still 5.20.

 

[sddawson]

Go to Bjango's Twitter page for a link to a new build (687). This stopped the spastic "deleted" process I was seeing in Sierra.

Where do I find the new build? Can't see anything on their Twitter page...
[doublepost=1474934012][/doublepost]Don't worry - I just downloaded it again from their main web site, and indeed the build number is 687 and the problem is fixed! Interestingly, those cache processes used to start (and quit) every time you launched the main iStat app too, but they don't anymore. I'll see if I can find out from the developer exactly what the problem was, for future reference.

 

[simonmet]

I'm kind of glad I gave up on that app, even after paying for it. I couldn't stand the UI in version 5.

 

[sddawson]

I'm kind of glad I gave up on that app, even after paying for it. I couldn't stand the UI in version 5.

Do you use anything in its place?

 

[simonmet]

No not yet. Guess it was never really that necessary for me.

 

[sddawson]

I find it pretty essential. After all, if I hadn't had iStat Menus I wouldn't have realised that iStat Menus was making the system consume too much CPU! But seriously, I really like seeing what's doing what on a continuing basis, checking download speed etc...

 

[simonmet]

Bjango have some really good UI articles on their home page, which is why I was surprised and disappointed at the low contrast, blurry grey text used in iStat Menus 5. Otherwise I'd still use it. In terms of functionality it's excellent.

 

[Alrescha]

Do you use anything in its place?

Believe it or not, I find Activity Monitor, with the main window closed and the CPU usage in the Dock one of the lightest-weight / lowest overhead system monitors around. If you need more detail the main window is only a click away.

A.

 

[sddawson]

Believe it or not, I find Activity Monitor, with the main window closed and the CPU usage in the Dock one of the lightest-weight / lowest overhead system monitors around. If you need more detail the main window is only a click away.

A.

Not sure about that. iStat Menus reports that the sysmond process uses more CPU when Activity Monitor is running than Activity Monitor reports iStat is using...

 

[Alrescha]

Not sure about that. iStat Menus reports that the sysmond process uses more CPU when Activity Monitor is running than Activity Monitor reports iStat is using...

You may be on to something. I tested using top with a one minute refresh rate to measure. I do not have iStat installed any more so I will defer to your more recent results.

A.

 

[sddawson]

There have been some updates to reduce its CPU consumption, and it uses very little - a bit more if you click on one of its icons.

 

[eostermueller]

Here we are years later in 2020, and bernie-uk 's four-year-old answer just fixed this problem for me on mac/Catalina.
I used terminal to delete ~/Library/Caches/
and then rebooted -- and there was a minute or so of a slowdown. Perhaps the caches were re-filling?
...but then it was all good!

This imac was approaching un-usable -- the delays from swirl busy cursor were 5-10 seconds and happened frequently, with almost every click/operation...but its all good now.

Helloooo Apple, this problem has been around for 4 years, any fix in sight?