Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

htop is using much cpu itself #1484

Open
webcaptcha opened this issue May 24, 2024 · 20 comments
Open

htop is using much cpu itself #1484

webcaptcha opened this issue May 24, 2024 · 20 comments
Labels
Linux 🐧 Linux related issues question ❔ Further information is requested support request This is not a code issue but merely a support request. Please use the mailing list or IRC instead.

Comments

@webcaptcha
Copy link

I'm on KDE Plasma on Wayland session

Terminal emulator - Alacritty
When I run htop it's usually shows around 15% CPU with peaks up to 25%

Is it ok? For example on the screenshot at the same time Firefox was playing video.
Screenshot_20240524_174128

If it needed I can make a video but almost all time it uses than numbers of CPU

CPU - AMD 7840HS
GPU - intergrated
RAM - 32GB

htop default config

@Explorer09
Copy link
Contributor

The CPU percentage displayed is per core, so when you have 16 CPU core (or threads) active, the maximum would be 1600%.
Do you consider this takes too much CPU usage?

@BenBE BenBE added support request This is not a code issue but merely a support request. Please use the mailing list or IRC instead. Linux 🐧 Linux related issues labels May 26, 2024
@natoscott
Copy link
Member

@webcaptcha are you using the default sampling interval (1.5s) or something more frequent?
Looks like you have over 2000 processes running there - visiting each in /proc does take a small amount of time and it all adds up. You might find some additional insights by adding the UTIME and STIME columns and observing htop there as well (I expect you'll see much higher kernel time than user time).

@BenBE
Copy link
Member

BenBE commented May 27, 2024

Can you provide a copy of your htoprc configuration file?

@ivanstepanovftw
Copy link

Same for me on Fedora and Debian. Even though I have 8C/16T, laptop at the summer just burns your knees, so you have to monitor what to close, and htop just shouldn't be running in the background. Not critical, but others do not experience high CPU usage by htop itself. I also did not find any relevant bug reports except this one.

image

My thoughts at first was that this high CPU usage is just at this exact point of the time when it refreshes info, but top shows exactly the same with independent refresh rate.

image

Here is mine ~/.config/htop/htoprc, I hope it helps.

Details

# Beware! This file is rewritten by htop when settings are changed in the interface.
# The parser is also very primitive, and not human-friendly.
htop_version=3.2.2
config_reader_min_version=3
fields=0 48 17 18 38 39 40 2 46 47 49 1
hide_kernel_threads=1
hide_userland_threads=1
hide_running_in_container=0
shadow_other_users=0
show_thread_names=0
show_program_path=1
highlight_base_name=0
highlight_deleted_exe=1
shadow_distribution_path_prefix=0
highlight_megabytes=1
highlight_threads=1
highlight_changes=0
highlight_changes_delay_secs=5
find_comm_in_cmdline=1
strip_exe_from_cmdline=1
show_merged_command=0
header_margin=1
screen_tabs=1
detailed_cpu_time=0
cpu_count_from_one=0
show_cpu_usage=1
show_cpu_frequency=1
show_cpu_temperature=1
degree_fahrenheit=0
update_process_names=0
account_guest_in_cpu_meter=0
color_scheme=0
enable_mouse=1
delay=15
hide_function_bar=0
header_layout=two_50_50
column_meters_0=LeftCPUs2 Memory Swap
column_meter_modes_0=1 1 1
column_meters_1=RightCPUs2 Tasks LoadAverage Uptime
column_meter_modes_1=1 2 2 2
tree_view=0
sort_key=46
tree_sort_key=0
sort_direction=-1
tree_sort_direction=1
tree_view_always_by_pid=0
all_branches_collapsed=0
screen:Main=PID USER PRIORITY NICE M_VIRT M_RESIDENT M_SHARE STATE PERCENT_CPU PERCENT_MEM TIME Command
.sort_key=PERCENT_CPU
.tree_sort_key=PID
.tree_view=0
.tree_view_always_by_pid=0
.sort_direction=-1
.tree_sort_direction=1
.all_branches_collapsed=0
screen:I/O=PID USER IO_PRIORITY IO_RATE IO_READ_RATE IO_WRITE_RATE PERCENT_SWAP_DELAY PERCENT_IO_DELAY Command
.sort_key=IO_RATE
.tree_sort_key=PID
.tree_view=0
.tree_view_always_by_pid=0
.sort_direction=-1
.tree_sort_direction=1
.all_branches_collapsed=0

I did not changed default refresh rate, I have only added sensors info, CPU frequency, majfaults and "hide userland process threads" or something like that.

@ivanstepanovftw
Copy link

Forgot to mention, my CPU is AMD too: AMD Ryzen 7 5800U. I don't remember that I had this issue with Intel before.

@cgzones
Copy link
Member

cgzones commented Aug 24, 2024

Could you try to disable CPU frequency or CPU temperature and check whether the behavior persists.

@BenBE BenBE added the question ❔ Further information is requested label Aug 24, 2024
@ivanstepanovftw
Copy link

ivanstepanovftw commented Sep 5, 2024

Tried to disable both CPU frequency and CPU temperature and restarting htop, CPU usage is the same before and after, behavior persisted.

Details

image

image

@ivanstepanovftw

This comment was marked as spam.

@ivanstepanovftw
Copy link

This fixes high load:

Subject: [PATCH] Commented function
---
Index: linux/LinuxProcessTable.c
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/linux/LinuxProcessTable.c b/linux/LinuxProcessTable.c
--- a/linux/LinuxProcessTable.c	(revision fc54b885ef75b8edacc4a9758f29b51e16025d34)
+++ b/linux/LinuxProcessTable.c	(date 1725503862876)
@@ -629,6 +629,7 @@
  * Read /proc/<pid>/maps (process-shared data)
  */
 static void LinuxProcessTable_readMaps(LinuxProcess* process, openat_arg_t procFd, const LinuxMachine* host, bool calcSize, bool checkDeletedLib) {
+   return;
    Process* proc = (Process*)process;
 
    proc->usesDeletedLib = false;

image

@ivanstepanovftw
Copy link

ivanstepanovftw commented Sep 5, 2024

Before fix image

Maybe changing buffer size will help, but I do not care. So htop relays on procfs? But why it even reads /maps?

@BenBE
Copy link
Member

BenBE commented Sep 5, 2024

There are two reasons for reading /proc/<pid>/maps:

  1. Library Sizes (size of shared libraries used by the process), which is not provided by the kernel since ancient times
  2. Process up-to-date marking (highlighting processes where binaries like libraries have been replaced, e.g. by an update)

The problem with these is BTW not the routine itself, but that the kernel is slow in providing these information. The parsing of these lines is already heavily optimized to avoid slow libc functions where ever possible.

@ivanstepanovftw
Copy link

Nice useful features! Can I disable them?

@BenBE
Copy link
Member

BenBE commented Sep 5, 2024

Yes.

  1. Library Size accounting is automatically disabled, when the corresponding column is not shown
  2. Up-to-date marking can be configured on the setup screen under Display Options using the checkbox labelled "Highlight out-dated/removed programs (red) / libraries (yellow)"

@ivanstepanovftw
Copy link

Unchecking "Highlight out-dated/removed programs (red) / libraries (yellow)" is the solution of this issue for me!

@schumischumi
Copy link

schumischumi commented Sep 20, 2024

For me unchecking "Highlight out-dated/removed programs (red) / libraries (yellow)" only reduces the cpu load.
If the feature is enabled htop shows 50% cpu load and after disabling it it's about 30%.
htop 3.3.0
Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.2
Kernel Version: 6.10.10-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-4790 CPU @ 3.60GHz
Memory: 15.5 GiB of RAM
Graphics Processor: AMD Radeon RX 5700
Manufacturer: ASUS
Product Name: All Series

@webcaptcha
Copy link
Author

Sorry for some delay from my side. Here in Ukraine the life is funny

@webcaptcha
Copy link
Author

with option "Highlight out-dated/removed programs (red) / libraries (yellow)" disabled
Screenshot_20240926_112024
wtih enabled
Screenshot_20240926_112054

Not much differences

@webcaptcha
Copy link
Author

Here is my config

config
# Beware! This file is rewritten by htop when settings are changed in the interface.
# The parser is also very primitive, and not human-friendly.
htop_version=3.3.0
config_reader_min_version=3
fields=0 48 17 18 38 39 40 2 46 47 49 1
hide_kernel_threads=1
hide_userland_threads=0
hide_running_in_container=0
shadow_other_users=0
show_thread_names=0
show_program_path=1
highlight_base_name=0
highlight_deleted_exe=1
shadow_distribution_path_prefix=0
highlight_megabytes=1
highlight_threads=1
highlight_changes=0
highlight_changes_delay_secs=5
find_comm_in_cmdline=1
strip_exe_from_cmdline=1
show_merged_command=0
header_margin=1
screen_tabs=1
detailed_cpu_time=0
cpu_count_from_one=0
show_cpu_usage=1
show_cpu_frequency=0
show_cpu_temperature=0
degree_fahrenheit=0
update_process_names=0
account_guest_in_cpu_meter=0
color_scheme=0
enable_mouse=1
delay=15
hide_function_bar=0
header_layout=two_50_50
column_meters_0=LeftCPUs2 Memory Swap
column_meter_modes_0=1 1 1
column_meters_1=RightCPUs2 Tasks LoadAverage Uptime
column_meter_modes_1=1 2 2 2
tree_view=0
sort_key=46
tree_sort_key=0
sort_direction=-1
tree_sort_direction=1
tree_view_always_by_pid=0
all_branches_collapsed=0
screen:Main=PID USER PRIORITY NICE M_VIRT M_RESIDENT M_SHARE STATE PERCENT_CPU PERCENT_MEM TIME Command
.sort_key=PERCENT_CPU
.tree_sort_key=PID
.tree_view_always_by_pid=0
.tree_view=0
.sort_direction=-1
.tree_sort_direction=1
.all_branches_collapsed=0
screen:I/O=PID USER IO_PRIORITY IO_RATE IO_READ_RATE IO_WRITE_RATE PERCENT_SWAP_DELAY PERCENT_IO_DELAY Command
.sort_key=IO_RATE
.tree_sort_key=PID
.tree_view_always_by_pid=0
.tree_view=0
.sort_direction=-1
.tree_sort_direction=1
.all_branches_collapsed=0

@BenBE
Copy link
Member

BenBE commented Sep 26, 2024

Does hitting Shift+H (disable showing threads) help?

@webcaptcha
Copy link
Author

Does hitting Shift+H (disable showing threads) help?

cpu consumption reduces by 2, was about 11-14, with shigt+h its 5-7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Linux 🐧 Linux related issues question ❔ Further information is requested support request This is not a code issue but merely a support request. Please use the mailing list or IRC instead.
Projects
None yet
Development

No branches or pull requests

7 participants