Suddenly Super Slow Mac Book Air on Catalina *** with Etre Report ***

There certainly wasn't a problem at the time that Activity Monitor screenshot was taken, but the EtreCheck data was obviously captured at a time coinciding with the performance degradation. In other words nothing is conclusive yet.

Please determine how your Mac works in "Safe Mode": Use safe mode to isolate issues with your Mac. A Mac is not particularly pleasant to use while in that mode but you should be able to draw a comparison to how it works normally (not Safe Mode).

Then, restart your Mac normally and observe again.

This is one major clue:

Major Issues:

  Runaway process - A process is using a large percentage of your CPU.

Top Processes Snapshot by CPU:

  Other processes 179.40 % (?)

Something is burdening that Mac's CPU, leaving it with little time to do much else. Find out what those processes are. To do that use Activity Monitor: View CPU activity in Activity Monitor on Mac - Apple Support.

In its View menu, select All Processes. Select the CPU tab, and click the CPU column to sort by %CPU in descending order (arrow pointing "down"). The burdensome process or processes will appear at the top. Identify them or post a screenshot.

Well, that's virtually identical to the original one. It should a runaway process and a file system timeout.

If you are running the Mac App Store version of EtreCheck, and it show a runaway process, you need to drop everything, right then, and run Activity Monitor. Otherwise, you'll never know.

Another option would be to download and use EtreCheckPro instead. EtreCheckPro isn't in the Mac App Store so it can directly report what these runaway processes are. Unfortunately, due to an updated Apple Support Communities Use Agreement, I can't give you a link to EtreCheckPro.

Taking that long merely to load a website is certainly unusual.

Safe Mode is useful in that it eliminates the effect of system modifications that often contribute to slow performance for which those "other processes" may be responsible. Generally speaking if a Mac runs poorly in Safe Mode hardware failure is the usual cause. I'm hesitant to suggest hardware failure in your case because there are many other factors involved with merely loading webpages over the Internet. If you find opening apps or copying files takes an inordinately long time though, it's another story.

Here is the relevant excerpt from http://www.etrecheck.com/features:

• EtreCheckPro is available directly from Etresoft. The price is USD $17.99 and all taxes are included. The Power User package in EtreCheckPro can be activated on up to 6 separate machines. 

I have no affiliation with EtreCheck or its developer. I do not know if it would help identify those "runaway processes" either—Activity Monitor should reveal them. Your screenshot of AM shows WindowServer taking somewhat more CPU than usual, but not so much that it should cause such an effect on performance.

WindowServer is the process responsible for drawing everything on a Mac's screen. If it remains at a relatively high %CPU you might try closing apps one at a time in an effort to determine if one of them is more responsible for it than any other.

Maybe post another EtreCheck report. The first one you posted with the runaway process also had a timeout on your filesystem test. I didn’t see any software that could account for that. Perhaps it was a temporary state caused by the generation of a local snapshot or something.

John Galt wrote:

I have no affiliation with EtreCheck or its developer. I do not know if it would help identify those "runaway processes" either—Activity Monitor should reveal them. Your screenshot of AM shows WindowServer taking somewhat more CPU than usual, but not so much that it should cause such an effect on performance.

Activity Monitor will definitely reveal it. EtreCheckPro will do it too. This is one area where being in the Mac App Store is problematic. I can only get information for user processes, not any processes owned by other users such as root. I really have to jump through some hoops to find those CPU usages. I was surprised that said hoops themselves even worked in the Mac App Store.

EtreCheckPro, however, can just run standard system tools like "ps" and "top" to find this information.

Considering the fact that the filesystem performance test fails at the same time, and the fact that this CPU using isn't all that high, this is probably the creation of a local snapshot. That could lock up the filesystem and cause the test to fail. It also tends to take 100% of one CPU core for kernel_task. This is probably not a kernel throttle where kernel_task is taking 500-1000% of the CPU.

It is probably normal and closely related to the low disk space on the boot drive.

👍

Lots of these problems seem to affect Macs with only 128 GB storage. I surmise local snapshots are not included in whatever is left, otherwise EtreCheck would have reported insufficient free space...?

Time Machine:

Time Machine Not Configured!

OP needs to do that too.

I did a lot of experimenting with Local Snapshots and TM a while ago that led me to conclude routine backups prevented them from accumulating to excess, but that's not supposed to happen anyway—see Apple's references to "plenty of free space" and "deleted automatically". I need to repeat those tests one day. They're time-consuming.

EtreCheck uses the system values for free storage space, reporting both “available” and “free”. Any space taken by local snapshots is accounted for. EtreCheckPro has a storage display that measures how much space is taken by each folder. In this display, local snapshots and a few other things can show up as a large “unknown” section.

As far as I can tell, the system does correctly purge free storage space as necessary. But there is also a separate process to alert the user about low storage space. These two processes run under different criteria. It is very confusing for people. They get an alert telling them they are out of space. Logically, they start deleting files. But nothing they do has any effect due to local snapshots. And then later, the system purges those local snapshots so the problem resolves itself. But the “fix” is a bare minimum. It may all happen again next week.