Zoomtopia is here. Unlock the transformative power of generative AI, helping you connect, collaborate, and Work Happy with AI Companion.
Register nowEmpowering you to increase productivity, improve team effectiveness, and enhance skills.
Learn moreKeep your Zoom app up to date to access the latest features.
Download Center Download the Zoom appDownload hi-res images and animations to elevate your next Zoom meeting.
Browse Backgrounds Zoom Virtual BackgroundsEmpowering you to increase productivity, improve team effectiveness, and enhance skills.
Zoom AI CompanionThe Zoom Community has won the Best Customer Support Community award!
Celebrate with us2022-03-17 03:33 PM
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?
2022-04-21 12:03 AM
I'm having the exact same issue om Ubuntu 21.10.
2022-06-22 06:31 AM
Same problem for me with Debian 11 on amd64 and Zoom 5.10.7 (but the problem has been present for a long time)
2022-08-11 11:37 PM
Same Ubuntu 22.04, zoom Version: 5.11.3 (3882)
2022-09-20 07:15 AM
2022-10-27 04:12 AM
The same for me - Ubuntu 22.04. Plz fix it zoom team.
2023-03-24 04:14 AM
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.
2023-04-20 09:16 AM
2023-05-15 08:53 AM
I have an update from Zoom support.
The dev team has found several locations to optimize.
There may be some hope for this soon.
2023-10-03 09:36 AM - edited 2023-10-03 09:38 AM
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
2023-10-03 09:57 AM
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.
2023-10-03 10:32 AM
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.
2023-10-12 07:27 AM
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.
2023-10-03 10:24 AM
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.