Zoom on Linux is using 2-7% CPU when idle

[rxtx]

Zoom on Linux is using ~2-7% CPU when idle and minimized to tray.

Tried on Ubuntu 20.04 and Debian 11 with KDE Plasma.

This drains my laptop battery.

How to fix it?

[Pascal80]

I'm having the exact same issue om Ubuntu 21.10. 

[nicolas_b]

Same problem for me with Debian 11 on amd64 and Zoom 5.10.7 (but the problem has been present for a long time)

[andyroid]

Same Ubuntu 22.04, zoom Version: 5.11.3 (3882)

[lebauce]

This is the case for all our company Linux computers. It eats an average of 7% when doing nothing - not in a meeting. Is it possible to have at least an acknowledge from the Zoom team ?

[kabell]

The same for me - Ubuntu 22.04. Plz fix it zoom team.

[gtf21]

Same problem, has been present for a long time (and I note this thread is 1y old now):

Zoom 5.14.0-1 on Archlinux (6.2.7 kernel)

Has been a problem for every version of zoom I have used for at least six months.

[casl]

This continues.  Zoom support says it's "expected".   

The client is consuming more CPU idle than Xorg.  🤔

[casl]

I have an update from Zoom support.

The dev team has found several locations to optimize.  

There may be some hope for this soon.

[bbcoder]

Zoom consumes ~100% of single CPU core when IDLE.. are you guys trying to mine crypto on my laptop ryzen 4500u?))
PS: Ubuntu Ubuntu 20.04.5 LTS

[gtf21]

FWIW I've noticed that it's always the same thread which chews up CPU time:

    /opt/zoom/zoom --type=utility --utility-sub-type=unzip.mojom.Unzipper --service-sandbox-type=utility [...]

Killing this process (SIGTERM) has no noticeable impact on Zoom -- calls still work just fine.

Would be interested to see if anyone else notices this behaviour.

[casl]

In my case, it was not the `--type=utility` process, but the top child in the process hierarchy. 

During idle, I see no activity at all for that `--type=utility` process at all.

[bsbernd]

I'm not sure about idle yet, but I noticed really high cpu usage after updating zoom in a meeting. Killing that mojom.Unzipper issue solved it.
https://community.zoom.com/t5/Meetings/Zoom-5-15-3-4839-on-Ubuntu-Linux-high-CPU-load/m-p/130200

Now need to find a solution how to automate that. Would be great if the zoom developers would fix it.

[casl]

After several back/forths with Zoom support over several weeks, there were some significant improvements made.

I'm running version 5.16.2 (8828) now on Ubuntu 22.04.3 LTS

CPU usage while idle (12-core i7) is between 1 & 2% of a single core.  If left idle for the day (8-10 hrs of work) & overnight, this still adds up to more CPU time than Xorg or Chrome.  I typically do not leave it idle, though, mostly from habit, and exit it after each meeting.

If you're not on the latest release, get that first, and make sure you have the Ubuntu updates too. 

You can attach to the process using strace and take a sample of what it's doing.  I was seeing a lot of time being wasted in poll() calls.  Zoom devs were able to tune some of these from the default values which made a significant difference.

With Zoom in an idle & minimized state, run `top` to identify the process ID of the zoom process (there will be several) that is consuming the CPU.  Once you find the Zoom PID that's consuming CPU, you can use this bash 1-liner to gather a 30-second sample of system calls via strace, inserting the PID appropriately.  

sleep 30 & strace -ttt -w -C -p ZOOMPID -o zoom_ZOOMPID.out & wait %1; kill %2

The end of the log file $ZOOMPID.out will have a summary of the calls.  Here's what I had from a sample taken back in April:

% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.89 27.713334 5785 4790 poll
0.04 0.010514 83 126 newfstatat
0.02 0.004661 87 53 read
0.01 0.003517 125 28 1 futex
0.01 0.003364 84 40 openat
0.01 0.002082 148 14 writev
0.01 0.001719 42 40 close
0.01 0.001504 1503 1 restart_syscall
0.00 0.001026 78 13 write
0.00 0.000690 172 4 gettid
0.00 0.000534 29 18 6 stat
0.00 0.000299 37 8 lseek
------ ----------- ----------- --------- --------- ----------------
100.00 27.743242 5402 5135 7 total

Verses a sample I just took today:

% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.78 28.821108 18998 1517 poll
0.10 0.029966 29966 1 restart_syscall
0.04 0.012954 117 110 newfstatat
0.01 0.004329 108 40 openat
0.01 0.004316 95 45 read
0.01 0.003799 135 28 5 futex
0.01 0.002728 194 14 writev
0.01 0.001839 45 40 close
0.01 0.001612 230 7 write
0.00 0.000962 192 5 gettid
0.00 0.000361 45 8 lseek
0.00 0.000225 224 1 getpid
0.00 0.000115 115 1 sendto
------ ----------- ----------- --------- --------- ----------------
100.00 28.884315 15896 1817 5 total

The CPU time is still being consumed by poll(), but the number of calls has been reduced from 4790 to 1517, so about 68%?

In any case, it should not be spinning 100% during idle.  The strace output might give you some idea of what could be causing that.