How to find memory hog? 37 GB swap Used after boot.

[saulinpa]

That's a new one. It looks like something in your install architecture is scrambled. Obviously EtreCheck is running wild with 30 minutes of runtime and 27 GB of memory. It's obviously the install system that's causing it. You shouldn't have all of those duplicated in your install history. Plus, when the operating system is tracking its own analytics, it's reporting heavy CPU usage from system_installd and installd.

I have seen similar problems in the past, but never to this degree. If the system install file was really huge, it could cause EtreCheck to slow down and consume lots of RAM because it would read the entire file into memory and parse it with a DOM parser. I changed that to use a SAX parser which definitively fixed the problem. EtreCheck only looks at installs in the past 60 days, so it can churn through a huge install XML file pretty quickly.

In your case, that isn't helping. You seem to have lots of duplicate entries in your install history. I don't know why. I've never seen that before. The install history is this file: "/Library/Receipts/InstallHistory.plist". Apple plist files are just a special syntax of XML. This file is typically only a few KB in size. How big is yours?

You might need to delete that file and then restart your computer. You'll lose your install history, of course. But other than that, it shouldn't cause any ill effects. And it should definitively fix this problem, both in EtreCheck and in your system startup.

It is 18 GBytes
-rw-rw-r-- 1 root admin 18733261205 May 26 22:36 /Library/Receipts/InstallHistory.plist

 

[smithrh]

It is 18 GBytes
-rw-rw-r-- 1 root admin 18733261205 May 26 22:36 /Library/Receipts/InstallHistory.plist

OMG

Edited to add: it would be interesting to see what is writing to that/what is in that .plist file. As noted, it can be deleted but that doesn't mean the problem won't occur again.

 

[saulinpa]

That's a new one. It looks like something in your install architecture is scrambled. Obviously EtreCheck is running wild with 30 minutes of runtime and 27 GB of memory. It's obviously the install system that's causing it. You shouldn't have all of those duplicated in your install history. Plus, when the operating system is tracking its own analytics, it's reporting heavy CPU usage from system_installd and installd.

I have seen similar problems in the past, but never to this degree. If the system install file was really huge, it could cause EtreCheck to slow down and consume lots of RAM because it would read the entire file into memory and parse it with a DOM parser. I changed that to use a SAX parser which definitively fixed the problem. EtreCheck only looks at installs in the past 60 days, so it can churn through a huge install XML file pretty quickly.

In your case, that isn't helping. You seem to have lots of duplicate entries in your install history. I don't know why. I've never seen that before. The install history is this file: "/Library/Receipts/InstallHistory.plist". Apple plist files are just a special syntax of XML. This file is typically only a few KB in size. How big is yours?

You might need to delete that file and then restart your computer. You'll lose your install history, of course. But other than that, it shouldn't cause any ill effects. And it should definitively fix this problem, both in EtreCheck and in your system startup.

I renamed the file and rebooted which seems to have fixed my problems. EtreCheckPro now runs in 2:34 minutes and my other updates are completing.

Thank you very much. My next step would have been wiping my Mac.

.......Receipts % ls -l
total 36588416
drwxr-xr-x 2 _installer admin 64 May 22 06:44 db
-rw-rw-r-- 1 root admin 2640 May 29 09:38 InstallHistory.plist
-rw-rw-r-- 1 root admin 18733261205 May 26 22:36 InstallHistory.plist.old

 

[chrfr]

You might also look at /var/log/install.log to see what the installer has been trying to do. My guess is that something has been either repeatedly installing or repeatedly failing to install. That log file might be useful to review.

 

[etresoft]

OMG

Edited to add: it would be interesting to see what is writing to that/what is in that .plist file. As noted, it can be deleted but that doesn't mean the problem won't occur again.

That's a good point. However, I see that you are running 26.6. That might be enough to explain it. The duplicate pattern is interesting. As the entries get older, the number of duplicates duplicates - 2 - 4 - 8 - 16 and maybe a lot more past the 60 day EtreCheck cut-off.

It's possible that this might be a relatively common event. That initial swap space usage after boot is something that I've seen other people report over the years. I'm going to add a specific test for this in the next version of EtreCheck. And I'll also do a better job at preventing those duplicates.

 

[saulinpa]

You might also look at /var/log/install.log to see what the installer has been trying to do. My guess is that something has been either repeatedly installing or repeatedly failing to install. That log file might be useful to review.

Log is 19 MB since it rolled over last week. With the huge plist file the installers have been failing and retrying so how would you determine cause vs effect? Maybe look at the archive log files?

% ls -l /var/log/install*
-rw-r--r--@ 1 root admin 19015759 May 29 10:49 /var/log/install.log
-rw-r--r-- 1 root admin 3287839 May 18 08:50 /var/log/install.log.0.gz
-rw-r--r-- 1 root admin 3021423 Nov 6 2025 /var/log/install.log.1.gz

With a quick look I saw that over half of the lines in the install.log file are "PackageKit: Skipping stale sandbox" alerts so I deleted the .PKInstallSandboxManager files to at least clear the background noise.

 

[saulinpa]

That's a good point. However, I see that you are running 26.6. That might be enough to explain it. The duplicate pattern is interesting. As the entries get older, the number of duplicates duplicates - 2 - 4 - 8 - 16 and maybe a lot more past the 60 day EtreCheck cut-off.

It's possible that this might be a relatively common event. That initial swap space usage after boot is something that I've seen other people report over the years. I'm going to add a specific test for this in the next version of EtreCheck. And I'll also do a better job at preventing those duplicates.

The swap issue was happening with 26.5 - I went to 26.6 hoping it had a fix.

# grep RosettaUpdateAuto InstallHistory.plist.old | wc
6811966 6811966 303132487

 

[ignatius345]

(This is like a textbook perfect support thread. OP provided super clear reports, and then the actual developer of the diagnostic software interpreted the results to fix the issue. Amazing.)

 

[TechnoMonk]

Swap space usage is not necessarily a concern if you rarely shutdown or close apps. OS will grab as much ram available and will offload not actively used to swap memory. Reboot should usually clear unless an app or installer is misbehaving.

 

[etresoft]

The swap issue was happening with 26.5 - I went to 26.6 hoping it had a fix.

Only the first two digits are significant. I have a separate computer dedicated to "beta" testing. But I haven't run any actual beta builds since Tahoe was released. Tahoe never really left beta quality stage. I even had to roll 26.4 back to 26.3.1 when News started crashing a few seconds after launch. There's no point in bothering with new builds when 27 comes out in a few days.

And to be clear, I'm not "testing" in the traditional sense. I'm identifying changes in system and API behaviour so I can code my apps to make sure they will work properly. When Apple releases a new bug, I assume it's permanent and an indicator of future fragility.

I think deleting the .PKInstallSandboxManager directory was the correct course of action.

 

[chrfr]

Log is 19 MB since it rolled over last week. With the huge plist file the installers have been failing and retrying so how would you determine cause vs effect? Maybe look at the archive log files?

That in itself is interesting. On this MacBook, the install.log file last rolled over on April 22 and the current log is only 8.2MB. On my Mac mini, the file is 12.3MB and last rolled on April 19.
It's more a curiosity than anything else at this point, since you seem to have sorted it out.