Element-desktop-nightly have more CPU usage

[progserega]

Steps to reproduce

1. start element-desktop-nightly
2. wait sync complyte
3. see cpu usage - element use ~60-70% cpu
   

Outcome

What did you expect?

use cpu in range 1-10% in idle

What happened instead?

more use cpu usege by element in range 60-70% in idle state

I was try start element with disabling gpu, but this was not help:
--disable-gpu --in-process-gpu

Operating system

Debian 12

Application version

Element-desktop-nightly 2024030901

How did you install the app?

official element.io repo for debian 12

Homeserver

matrix-synapse-py3 1.89.0+bullseye1

Will you send logs?

Yes

[progserega]

So it is use more IOPS in idle mode at end of work day:

Total DISK READ:         0.00 B/s | Total DISK WRITE:      1318.67 K/s
Current DISK READ:     811.49 K/s | Current DISK WRITE:      50.72 K/s
    TID  PRIO  USER     DISK READ DISK WRITE>    COMMAND                                                                                                                                                                                                                         
 231800 be/5 progsere    0.00 B/s 1217.23 K/s element-desktop-nightly --use-gl=angle --use-angle=swiftshader --disable-gpu --in-process-gpu [ThreadPoolForeg]
 231802 be/5 progsere    0.00 B/s   50.72 K/s element-desktop-nightly --use-gl=angle --use-angle=swiftshader --disable-gpu --in-process-gpu [ThreadPoolForeg]
 231860 be/5 progsere    0.00 B/s   50.72 K/s Element-Nightly --standard-schemes=vector --enable-sandbox --secure-schemes=vector --fetch-schemes=vector --share~reMediaKeyHandling,MediaSessionService,SpareRendererForSitePerProcess --variations-seed-version [ThreadPoolForeg]
      1 be/4 root        0.00 B/s    0.00 B/s systemd --switched-root --system --deserialize=40
      2 be/4 root        0.00 B/s    0.00 B/s [kthreadd]

My system setup ssd as lvm cashe. So this stat say, that many writes in spool of lv (from element?):

  LV      |LSize  |Meta% |Data% |Cpy%Sync|CacheDirtyBlocks|CacheReadHits   |CacheReadMisses |CacheWriteHits  |CacheWriteMisses
  media   |  1,36t|      |      |        |                |                |                |                |                
  boot    |400,00m|      |      |        |                |                |                |                |                
  home    |300,00g|0,24  |36,03 |9,66    |           27915|        20973684|         1042003|       156614161|          970100
  root20  | 60,00g|      |      |        |                |                |                |                |                
  root_deb| 60,00g|1,93  |65,09 |0,00    |               0|        11912272|         1391761|        79229507|          626706
==============================================================================================================================

May be it is "migration proccess" by Rust lib? But it is continue second day...

[t3chguy]

This is a known issue with Rust Crypto indeed

[t3chguy]

Related #1444

[progserega]

May be exist any hack? Clear data, disable search in encrypted rooms?

[t3chguy]

Yes, likely disabling message indexing would alleviate it.

[richvdh]

This is a known issue with Rust Crypto indeed

I'm not aware of such an issue.

[progserega]

Yes, likely disabling message indexing would alleviate it.

Disabling "search in encrypting room" - not help. :-(

[richvdh]

May be it is "migration proccess" by Rust lib? But it is continue second day...

We haven't yet rolled out a migration process for existing sessions for Element Desktop builds; unless you've overridden the configuration, the Rust crypto library will currently only be used for new logins, or if you explicitly enable it via the "labs" setting in the UI.

So, is this a new login? Or did you enable Rust Crypto some other way?

[progserega]

No, it is not new login. Config dir was on my disc from old time ago. But some days ago I was begin use element-desktop-night again (because element-desktop not started - after every start - his kill by OOM-killer: #1564 ).

Now I try "clear cache and restart" in settings of element-desktop-nightly, but after restart "CPU/IO eating" was continue...

[progserega]

I was not enable Rust encrypting. It was enabled by default. I can not disable it - splash said: "Rust cryptography can not be disabled on this deploiment of Element Nightly".

[richvdh]

ohhh. yes. This was a bug in our implementation of the rust labs option: sessions which had not been used since before v1.11.18 will be automatically migrated. Well, that explains why you're on Rust Crypto, but doesn't explain why it's a problem.

There's no particular evidence here that it is rust crypto that is the problem. @t3chguy: I see a lot of element-hq/element-web#27173 going on in the logs: could it be that?

[t3chguy]

@richvdh unknown, haven't dug into that issue, maybe the maintainer knows something about it

[progserega]

@richvdh

but doesn't explain why it's a problem.

Do it is normal, when migration continue 2 work days (~28 hour) with hard use I/O and CPU? I think not. I think it is normal not more maximum 2 hour.
Okey, migration - hard, but why it is continue when I clear cache (in it options) of Element-desktop-nightly?

[richvdh]

but doesn't explain why it's a problem.

Do it is normal, when migration continue 2 work days (~28 hour) with hard use I/O and CPU? I think not. I think it is normal not more maximum 2 hour. Okey, migration - hard, but why it is continue when I clear cache (in it options) of Element-desktop-nightly?

I think you misunderstand me. I agree there is a problem here. My point is: I now understand why you are using Rust crypto; but I do not understand what has caused your problem. I think it is unrelated to Rust crypto.

For clarity: I'm leaving this for the Element-web team to investigate.