Why 15-ish % CPU usage when idle in tray ? [Under investigation, can reproduce]

gwallet

First of all, I'm very pleased to see the support of Linux, many thanks to all of who made this possible 🙂

I'm also glad to be part of those who help making it better, so here is my point:

Once launched and then closed, the process is still "running" as shown by the tray icon.
Then, I use htop to see resource consumption as my computer is doing nothing, the top 3 processes are '/opt/1Password/1password' (respective CPU usage: ~7%, ~4%, ~3%), the two lasts are children of the first one

My expectation is that when no graphical user interface is active, then the CPU consumption must be close to 0%

Here is my config:
1Password 0.8.4 installed via dnf
Fedora Workstation 31
GNOME 3.34.7 / X11
Intel open source graphic driver / NVidia Driver 440.100 for offloading 3D graphics
Linux Kernel 5.7.11.100

Hope it helps!

Best regards.

---

1Password Version: 0.8.4 (Linux Development Preview)
Extension Version: Not Provided
OS Version: Linux 5.7.11 / Fedora Workstation 31 / GNOME / X11
Sync Type: Not Provided

MikeT

Hi @gwallet,

Welcome and thanks for taking the time to report this.

Interestingly enough, I am not able to reproduce this with Gnome 3.36.3 on Pop!_OS 20.04. I tested this on Fedora and can reproduce your issue quickly.

It's very odd, I ran the app in the debug build on Fedora and there's zero activity while it is eating up the CPU.

We'll investigate and let you know what we find.

lieverse

I'm seeing similar loads on Ubuntu 18.04 LTS with Gnome 3.28, kernel 4.15, and the 1Password snap (0.8.5)

The load of the main/parent 1password process remains at around 10-13% both with the UI open and closed. Another process comes and goes when the UI is opened/closed, and that takes around 6%. A third process takes around 2% when the UI is open.

For comparison: the slack application, which I think is also an Electron app, is idling at < 0.5% (all processes) whether the UI is open or not, only spiking when the UI is just opened.

EDIT: just noticed that while on the lock screen, the UI process even goes up to 40-75%, just waiting for me to enter my master password. The main/parent process at that time goes to 20-25%, and the third parocess to about 11%.

MikeT

Hi @lieverse,

Thanks for reporting this.

There may be a few things going on at the same time.

First, can you tell me the spec of your CPU / GPU?

EDIT: just noticed that while on the lock screen, the UI process even goes up to 40-75%, just waiting for me to enter my master password.

This is a known optimization issue that we will address in the near future; the animations shouldn't be running if it is not focused but it is, so that is spinning up the CPU/GPU unnecessarily.

The load of the main/parent 1password process remains at around 10-13% both with the UI open and closed.

This looks like the same issue with 1Password on Fedora 32 for me, I can reproduce it there. We're still trying to find the cause as right now, our developers can't reproduce it on their machines, except for me in the virtual machines. We'll track it down soon.

lieverse

First, can you tell me the spec of your CPU / GPU?

I'm using a Dell Precision 5530, but using the Intel GPU and not the NVIDIA one (to avoid dock/undock issues).

# cat /proc/cpuinfo | grep 'model name' | head -1
model name:      : Intel (R) Core(TM) i7-8850H CPU @ 2.60GHz
# lspci | grep ' VGA '
00:02.0 VGA compatible controller: Intel Corporation Device 3e9b
# glxinfo | grep 'Device:'
    Device: Mesa DRI Intel(R) UHD Graphics 630 (CFL GT2) (0x3e9b)

This is a known optimization issue that we will address in the near future; the animations shouldn't be running if it is not focused but it is, so that is spinning up the CPU/GPU unnecessarily.

The only animation I can see on that lock screen (when not yet entered the master password) is a blinking cursor, so even when focussed I wouldn't expect to see such high CPU loads. When unlocked, and clicking in the search box to get a blinking cursor, I don't see these high loads either.

MikeT

@lieverse,

The only animation I can see on that lock screen (when not yet entered the master password) is a blinking cursor, so even when focussed I wouldn't expect to see such high CPU loads.

Look at the blue inner ring and the outer gray bars on left/right side of the ring. The bar fades in and out and the blue color shift as it rotates.

not the NVIDIA one (to avoid dock/undock issues).

I know what you mean, I have that same issue on my ThinkPad with nvidia GPU.

lieverse

Look at the blue inner ring and the outer gray bars on left/right side of the ring. The bar fades in and out and the blue color shift as it rotates.

Oh wow, that is so subtle (esp. the blue) that I didn't even notice. As an engineer it would make me wonder if that is worth 50% CPU load (for a screen that you wouldn't be looking at for a long time anyway), but I guess the UX dept would see that differently :-)

MikeT

@lieverse,

Oh wow, that is so subtle (esp. the blue) that I didn't even notice.

:smile: I do think it is too subtle but the design is not final in the current development builds.

As an engineer it would make me wonder if that is worth 50% CPU load (for a screen that you wouldn't be looking at for a long time anyway), but I guess the UX dept would see that differently :-)

It's not but even small animations like that shouldn't cause that big of a load, at the very least, it shouldn't do anything when not focused. I do suspect there is more to it than just the animation itself. I have reported a few other issues that is related to CPU usage during my testings but our engineers aren't yet able to reproduce it. We'll track them down and get it fixed.

looselyrigorous

I think it's related to Wayland. I'm running SwayWM and I also observe about 10% load. Also taking into account that Pop! defaults to X session and Fedora Wayland...

Edit: Oh bummer, OP uses an X session so it can't be that. D:

MikeT

That was a good guess, though.

I did rule it out when one of our engineers also use Fedora on his main machine and it doesn't show the same problem. Sadly, it is not as simple as we'd like it to be.

@looselyrigorous thanks for writing in with your setup, that'll help us collect more data.

vst

I am observing a similar load for the process /snap/1password/5/app/1password --no-sandbox.

I am using Dell Latitude 7300 with pre-installed Ubuntu. Relevant system information is:

 OS: Ubuntu 18.04 bionic
 Kernel: x86_64 Linux 4.15.0-1096-oem
 Resolution: 4720x1920
 DE: GNOME
 WM: GNOME Shell
 WM Theme:
 GTK Theme: Adwaita-dark [GTK2/3]
 Icon Theme: ubuntu-mono-dark
 Font: Ubuntu 11
 CPU: Intel Core i5-8365U @ 8x 4.1GHz [25.0°C]
 GPU: Mesa DRI Intel(R) UHD Graphics 620 (WHL GT2)
 RAM: 8001MiB / 15854MiB

Please let me know if I can help you any further.

MikeT

We will, thank you for including that spec, @vst.

gwallet

Hi everyone, me again.

I moved to the latest 1Password 0.9.1 (at the time of writing this), and to see that the load is now a bit worse than before 😕

I also planned to move to the recently released Fedora 33 Workstation. Once done, I'll keep you posted on how the environment affects the trend.

Regards

MikeT

Thanks for the update, we haven't been able to pinpoint it yet.

ref: dev/core/core#2718

[Deleted User]

Using 0.9.1 Appimage on Manjaro (see below), i see at an average a CPU utilization of 2.4% (Trayed and not-Trayed):

INFO  2020-10-30T12:34:41.938 op_executor:invocation_loop [op-app/src/app.rs:132] App::new(<redacted>/<redacted> (EN_US) Some(<redacted>))
INFO  2020-10-30T12:34:42.022 op_executor:invocation_loop [op-app/src/app/backend/config.rs:33] Settings changed.
INFO  2020-10-30T12:34:48.151 op_executor:invocation_loop [op-data-layer/src/load.rs:208] loaded <redacted> items in <redacted> vaults for account: <redacted>
ERROR 2020-10-30T12:34:48.153 op_executor:invocation_loop [op-app/src/app/backend/unlock.rs:92] NotImplemented
INFO  2020-10-30T12:34:48.153 op_executor:invocation_loop [op-app/src/app/backend/unlock.rs:100] Lock state changed: Unlocked
INFO  2020-10-30T12:34:48.153 ThreadId(15) [client:typescript] Lock Manager started.
INFO  2020-10-30T12:34:54.474 tokio-runtime-worker [op-data-layer/src/sync.rs:159] synced account: <redacted>
INFO  2020-10-30T12:34:54.474 op_executor:invocation_loop [op-data-layer/src/load.rs:50] reloading data layer...
INFO  2020-10-30T12:34:54.545 op_executor:invocation_loop [op-data-layer/src/load.rs:208] loaded <redacted> items in <redacted> vaults for account: <redacted>
INFO  2020-10-30T12:35:01.178 op_executor:invocation_loop [op-app/src/app/backend/frontend.rs:11] Front end event: window closed
INFO  2020-10-30T12:37:52.446 tokio-runtime-worker [op-syncer/src/sync_job.rs:580] Updated <redacted> items in vault <redacted>
INFO  2020-10-30T12:37:52.467 op_executor:invocation_loop [op-data-layer/src/load.rs:50] reloading data layer...
INFO  2020-10-30T12:37:52.514 op_executor:invocation_loop [op-data-layer/src/load.rs:208] loaded <redacted> items in <redacted> vaults for account: <redacted>
INFO  2020-10-30T12:37:58.830 tokio-runtime-worker [op-syncer/src/sync_job.rs:580] Updated <redacted> items in vault <redacted>
INFO  2020-10-30T12:37:58.887 op_executor:invocation_loop [op-data-layer/src/load.rs:50] reloading data layer...
INFO  2020-10-30T12:37:58.946 op_executor:invocation_loop [op-data-layer/src/load.rs:208] loaded <redacted> items in <redacted> vaults for account: <redacted>
kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but no Exec line
kf.service.sycoca: Invalid Service :  "/usr/share/applications/qemu.desktop"
Wird in einer aktuellen Browsersitzung geöffnet.
INFO  2020-10-30T12:41:18.841 op_executor:invocation_loop [op-app/src/app/backend/frontend.rs:11] Front end event: window closed

Operating System: Manjaro Linux
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1
Kernel Version: 5.8.16-2-MANJARO
OS Type: 64-bit
Processors: 6 × Intel® Core™ i5-9500T CPU @ 2.20GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 630

andrwhmmr

Got 12% CPU Load minimized to tray, Ubuntu 20.04.1, Lenovo T15, i7-10510U

MikeT

Hi guys,

It would also be useful to know how you install 1Password when you describe your hardware/software setup; for an example, via snap, appimage, or via apt. It'll help us narrow it down.

@andrwhmmr, how did you originally install 1Password?

lieverse

I have moved from snap (as mentioned in an earlier comment) to apt.

With version 0.9.3-31838 (apt) I'm still seeing similar loads as back then (snap), with UI closed or opened, and when viewing the lock screen (which still gives spikes to at least 70%).

andrwhmmr

I installed it via the apt-get on my notebook.

But I just installed 1pass on Manjaro via the AUR. (Thanks for that by the way!)
And on my desktop (i5 3570) I am seeing ~10% CPU Load when minimized to tray.

MikeT

Thanks, that rules out the specific package formats. I've passed on your specs to our team to continue investigating.

gwallet

Hi there!

I just moved to Fedora Workstation 33 and the issue still remains, not better nor worse:

Here's my config:

• 1Password 0.9.6 (Production) installed as RPM via dnf
• GNOME 3.38.2 / X11
• Linux Kernel 5.9.11-200.fc33
• Mesa driver 2.99.917-48.20200205.fc33
• NVidia Driver with Optimus support 455.45.01-1.fc33

It doesn't change anything whether the vault is locked or not.

Hope it helps,

Regards

Blake

Thanks for posting that!

We're still investigating things currently, but that certainly helps! 💙

aral

I’m also seeing this. In case it helps:

Installed via apt: 1password/edge,now 0.9.7-34739 amd64

System details:

OS: elementary OS 5.1.7 Hera x86_64 
Host: LabTop Mk IV 
Kernel: 5.4.0-58-generic 
Uptime: 12 days, 3 hours, 52 mins 
Packages: 2047 
Shell: zsh 5.4.2 
Resolution: 3840x2160 
DE: Pantheon 
WM: Mutter(Gala) 
Terminal: io.elementary.t 
CPU: Intel i7-10710U (12) @ 4.700GHz 
GPU: Intel Device 9bca 
Memory: 8388MiB / 15883MiB 

Dayton_ag

Hi @aral, welcome to the 1Password Community!

Thanks so much for sharing your system info! This will be helpful as the Development team continues to investigate this issue. :smile:

MikeT

Hi folks,

Please check your package manager for a 1Password update (0.9.9), we think we've addressed the issue with the high CPU idle usage.

Let us know how it is working out now on your systems, thanks!

vst

Hello Mike,

Thanks for the effort.

Confirming that 1Password no longer uses noticeable CPU when idle on tray (almost always 0%) in my case.

1Password version installed via snap (upgraded by sudo snap refresh 1password):

$ 1password --version
1Password version: 0.9.9-3

Operating system details:

$ screenfetch -n -d "-host;-uptime;-pkgs"
 OS: Ubuntu 18.04 bionic
 Kernel: x86_64 Linux 5.4.0-62-generic
 Shell: zsh 5.4.2
 Resolution: 1600x900
 WM: Awesome
 WM Theme:
 GTK Theme: Adwaita-dark [GTK2/3]
 Icon Theme: Humanity
 Font: Ubuntu Light 11
 CPU: Intel Core i5-8365U @ 8x 4.1GHz
 GPU: Mesa DRI Intel(R) UHD Graphics 620 (WHL GT2)
 RAM: 5068MiB / 15827MiB

htop output while minimized on the tray:

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
31419 vst        20   0 4851M  163M  110M S  0.0  1.0  0:10.06 /snap/1password/20/app/1password --no-sandbox
31690 vst        20   0  542M 82348 52124 S  0.0  0.5  0:09.43 /snap/1password/20/app/1password --type=gpu-process --field-trial-handle=8323604638667257544,18227855775617691101
31719 vst        20   0  457M 63624 53800 S  0.0  0.4  0:00.66 /snap/1password/20/app/1password --type=utility --utility-sub-type=network.mojom.NetworkService --field-trial-han
31631 vst        20   0  376M 44268 36460 S  0.0  0.3  0:00.18 /snap/1password/20/app/1password --type=zygote --no-zygote-sandbox --no-sandbox
31632 vst        20   0  376M 44352 36540 S  0.0  0.3  0:00.29 /snap/1password/20/app/1password --type=zygote --no-sandbox

Note that I see some CPU activity on htop output while 1Password window is drawn. But this is not the subject of this discussion.

MikeT

Hi @vst,

That's great to hear, thanks for confirming that for us.

Note that I see some CPU activity on htop output while 1Password window is drawn. But this is not the subject of this discussion.

There will be a tiny CPU usage when you're viewing an item that has a timer animation for the one-time password fields. If you view an item without any animations, it should settle down to 0 quickly.

gwallet

Hi there!

Indeed, the new 0.9.9 release fixes the issue for me too.
I can't reproduce the CPU consumption when in tray (by the way, was still there in the 0.9.8 release …)

Happy days!

many thx! 🙂

Dayton_ag

Hey @gwallet, that's great! We're glad to hear the new update is working for you too :smile: :+1:

hansdezwart

For me 1password is showing still very high CPU usage. I am not sure when this started. I noticed my cooling starting to make noise yesterday, looked at top and found 1password was the culprit. I then found this thread.

This is my 1password version:

$ 1password --version
8.0.34

And here are my system details:

$ screenfetch -n -d "-host;-uptime;-pkgs"
 OS: Ubuntu 20.10 groovy
 Kernel: x86_64 Linux 5.8.0-59-generic
 Shell: bash 5.0.17
 Resolution: 3840x2400
 DE: GNOME 3.38.3
 WM: Mutter
 WM Theme: Adwaita
 GTK Theme: Yaru-light [GTK2/3]
 Icon Theme: Yaru
 Font: Ubuntu 11
 Disk: 85G / 916G (10%)
 CPU: 11th Gen Intel Core i7-1165G7 @ 8x 4.7GHz [56.0°C]
 GPU: Mesa Intel(R) Xe Graphics (TGL GT2)
 RAM: 6699MiB / 15721MiB

And this is my top output:

Dayton_ag

Hey there @hansdezwart, I'm really sorry you're seeing high CPU usage!

Are you seeing this usage when using and interacting with 1Password, or only when 1Password is idle? When the 1Password window is closed, does 1Password still show in your top output? Is %CPU still high, even when 1Password is only running in tray? I just had a go with trying to reproduce this (Ubuntu 20.10, Mutter) and didn't get much in the way of usage spikes.