CPU consumption. 80-90% on dual xeon e5-2689

[sunhort]

Technical information

Using version:

• [ x] master (running from GitHub-published source code, currently v3.0.0-pre)
• latest (latest release, currently v2.2.2)
• vX.X.X (specify other version)

Running on:

• [x ] Linux
• Windows
• macOS

How comfortable you are with your system and/or IT in general:

• I'm kind of lost, honestly
• I know what's up, I could help you run some commands or checks
• [x ] My machine is fully under my control, tell me what you need
• I attended Defcon last year

---

Problem

I had tested the ui under vbox with kubuntu 20, consumes all cores just to run the app (installed). Are you mining on my machine?

[GitSquared]

Are you mining on my machine?

No, and if you're running from source you can verify that.

run the app (installed)

What does "installed" mean here?

[Animus-Surge]

The CPU usage is mainly the multithreader scaling to multiple cores to boost how well it runs. There is absolutely no mining happening here (nor do I think the language used to make edex even supports mining).

[GitSquared]

Yeah, it shouldn't go to 90% though, unless the CPU clock is really low.

(nor do I think the language used to make edex even supports mining)

...you'd be surprised.

[Animus-Surge]

...you'd be surprised.

Looks like I stand corrected

[sunhort]

Installed means that I installed the app into the system not just started it from appimage (but it does the same thing if I just run it). Ok, if you not mining on my machine then how is it possible that software takes 28 threads? If I set 4, it takes 4. Very strange behavior. And what means "Multithread worker started at 27826" in starting massage. Also on 28 cores it is so slow in mc that I cant really use it. The clock is 2600 MHz on e5-25689 xeons

[sunhort]

IDK, may be it does that on KDE only, I'll check ubuntu mate and debian as well as soon as archives will get unpacked

[sunhort]

On debian 10 under vm ~20-30 % of 8 cores of the VM which is too much anyway for the terminal app, however the idea is great and could run into a good-looking ssh management system (probably with monitoring functions) as client (-server, could be done with snmp) app .

[wrac4242]

i can confirm that the software does use a large amount of CPU, though the load is spread over many cores, which helps
The issue is probably code efficiency, which is always 'fun' to deal with, and takes time, see #769

[sunhort]

i can confirm that the software does use a large amount of CPU, though the load is spread over many cores, which helps
The issue is probably code efficiency, which is always 'fun' to deal with, and takes time, see #769

Seems a bit strange to consume that much of the power to render a globe and show current stats of the mem/cpu

[lebarde]

To add my word:
On my Debian with a core i7 3770K, I get a 18% average consumption of my CPU while eDEX is running idle.
On the same system with xfce4-terminal running htop on the foreground, I get a 1,1% average consumption. See my conclusions about bootup time.

[GitSquared]

On my Debian with a core i7 3770K, I get a 18% average consumption of my CPU while eDEX is running idle.

Where did you read the percentage?

re:thread, I wonder if limiting the amount of threads edex uses may help. It was not designed with 28 available threads in mind... maybe the overhead is actually surpassing the performance benefits.

[lebarde]

Where did you read the percentage?

Directly inside eDEX-UI, I make an average of cores 1-4 and 5-8 and see if it is consistent in time.

[wrac4242]

my windows laptop is an i3, and uses about 25% CPU, i remember something similar to that on my Linux pc, so it is probably the amount of cores

[GitSquared]

I've limited the number of threads roughly according to the number of modules querying system info at each cycle.

Also on my XPS notebook with an i7 I found that edex's workload seems to trigger TurboBoost, which is not really desirable... The CPU's clock rockets to very high frequency, kicking in the fans to cool it down, while CPU usage stays around 20%. It would be much better if we could tweak that to lower CPU speed at the cost of a higher average use... I'm not sure if that's something we can do from tweaking the app.

[GitSquared]

@sunhort if you could confirm that the fix I pushed worked on your dual xeon system, I think we can close this!

[sunhort]

thank you for answering the question, some people say it's about electron's performance overall issue, I'll check your workaround soon. I wonder if it will be capable of running multi-threaded apps with all power as I limit edex-ui (because it will be parent process for this apps). So far how many modules it needs? 7 or less?

[GitSquared]

eDEX won't use more than 8 threads with this new patch. Note that when we talk about a "2x6 cores, 28 threads" system like your dual-xeons beast, it doesn't mean it cannot handle more than 28 threads, it just means that on one CPU cycle it can execute 28 of them at the same time.

You should be fine using both edex and other multithreaded apps. Most modern systems handle hundreds of threads without breaking a sweat - for instance, my 6 cores 12 threads notebook is currently managing 387 of them.