Big Sur keep consuming cpu(secd, cloudd, cdpd, Mail.app)

The core concept here is multi cores.

The percentage consumptions of CPU in process list is based on SINGLE core. So if the process supported multi threads (which is common now) it could use several cores together. So 80% means the TOTAL of actual working time divide by the time real world elapses. So 200% can be treated as TWO cores, 100% each. (But not exactly. Just as an assumption.)

And the percentages in the bottom of "Activity Monitor.app" are calculated combining all cores. So it shows the summary consumption of the whole platform.

UPDATE:

After some efforts contacting with technical support issues are almost resolved(I will update again if it continued).

I will go deeper later and make a brief first:

1. Reboot to safe mode (by holding shift when booting) and let it run for a while (typically 15 minutes) and try to use it normally. Issue may still continue under safe mode though.

2. Reboot normally and cdpd/cloudd may go back to normal.

For Mail.app I know the issue may be caused by two IMAP accounts(provided by 163.com) of all my accounts. So I managed to recreate them in POP mode (not IMAP) and it turns to be all right now.

DETAILS:

First I reached to technical support of Apple this morning. I should say thanks to Apple at this point (By selecting "Buy Mac OSX Recently" and you can get support even you run out of warranty). And I really suggest everyone should have a try if you really suffer issues because community is for users only.

I described the issues technically. Beyond my expectations the advisor (Her name is Angeli and Kevin in later case) could really understood them. We talked much and she did her best and used all the resources she could use helping to locate the cause or solutions. Finally she suggested to boot in safe mode to see whether issues continued.

When I came into safe mode I found things were the same or even worse(Figure 1). I tried to contact support again but I found there was no chat option any more. Also I forgot to keep the previous case number before I cannot use it to reenter. After about 15 minutes' struggling I rebooted back to normal.

Figure 1: Issues continued in safe mode

So miracle happened. "cdpd" and "cloudd" looked reasonable. I continued to work for a few hours and they didn't become insane again. So weird!

Anyway I had moved forward a lot.

So I still have a Mail.app issue(Figure 2). But at this time things were different from that under Catalina it seemed like it wouldn't exhaust the memory anymore. (So is "accountd")

Figure 2: Mail.app issue

And I had made some research on it before and concluded it was related to my two IMAP accounts(from 163.com). I didn't know why. Maybe there were some compatible issues between Mail.app and appleimap.163.com. Though 163 mail provides POP3 service Mail.app has integrated 163 already. I just can't create the account manually(Mail.app will automatically integrate it internally after you enter the informations, thus, using IMAP).

After some struggles I found a solution on it finally.

When I entered the information manually I use a wrong password. Then Mail.app will complain it and ask me to complete the service address, type, username manually which enables me to customize them. So I can force it adding as a POP3 account.

After I have done that I brought Mail.app back to normal finally.

Time to celebrate!

Figure 3: Everything work correctly

Oh I have a bad news. Things came back.

But the solution for Mail.app still works.

I spend more time on it and found an easy but ugly workaround. If you suffered this it makes it possible to wait for a new release of Big Sur with less pain.

The approach is based on the root cause process: cloudd.

We can kill it periodically if it was running. So I wrote a shell script and invoke it periodically by CRON service.

The script is like:

#!/bin/sh

PID=$(pgrep ^cloudd$)

if [ "no$PID" = "no" ]; then

exit

fi

kill $PID

Put it where you like and edit cron rule by running "crontab -e" in terminal:

* * * * * /Users/[path-to-it]/check_cloudd

Not perfect solution but better.

Surely a more better result you can get if you run it more frequently (eg. every 30 seconds). But you must turn to use other schedulers. Not necessarily I think.