Any idea what this process 51 is? I can’t send my system into suspend also. it sometimes happens and I don’t know why, is it a bug or a maleware. It is this process and sometimes it shows Xorg using too much CPU which goes up to 80-90% even. It fixed after rebooting.
Not a malware. It’s part of the Linux Kernel’s Transparent HugePage support (THP). According to the Linux kernel’s documentation:
Transparent Hugepage Support maximizes the usefulness of free memory if compared to the reservation approach of hugetlbfs by allowing all unused memory to be used as cache or other movable (or even unmovable entities). It doesn’t require reservation to prevent hugepage allocation failures to be noticeable from userland. It allows paging and all other advanced VM features to be available on the hugepages. It requires no modifications for applications to take advantage of it.
Applications however can be further optimized to take advantage of this feature, like for example they’ve been optimized before to avoid a flood of mmap system calls for every malloc(4k). Optimizing userland is by far not mandatory and khugepaged already can take care of long lived page allocations even for hugepage unaware applications that deals with large amounts of memory. In certain cases when hugepages are enabled system wide, application may end up allocating more memory resources. An application may mmap a large region but only touch 1 byte of it, in that case a 2M page might be allocated instead of a 4k page for no good. This is why it’s possible to disable hugepages system-wide and to only have them inside MADV_HUGEPAGE madvise regions.
Embedded systems should enable hugepages only inside madvise regions to eliminate any risk of wasting any precious byte of memory and to only run faster. Applications that gets a lot of benefit from hugepages and that don’t risk to lose memory by using hugepages, should use madvise(MADV_HUGEPAGE) on their critical mmapped regions.
You can disable THP if you want. See this:
1 Like
Thanks, It stopped to do that. Maybe it has been a issue with EOS recently and got fixed. But I could not run long without rebooting lately. For example last night one of my monitors got kinda frozen (it is a bit hard to explain) and stayed that way when I switched workspaces while the other one worked normally.
That’s unlikely to be the case. As mentioned in that article, THP is part of the Linux Kernel, so it has nothing to do with EndeavourOS per se. If it exhibits the behavior on your current set-up, then it should (logically speaking) exhibit the same behavior on any system that runs the same kernel version.
Have you updated the kernel recently? If you have, then that may be the case. But if you haven’t performed any kernel updates recently, it’s impossible that things got “fixed.”
As far as I know, there hasn’t been an update for the stable kernel since before the new year. There was an update for the lts kernel today, though.
It would take a lot more detective work to diagnose problems like this. For starters, we need to consider how much system resources (RAM, in particular) you have to begin with. If your system starts to slow down after prolonged usage, it could be a sign of memory exhaustion, which may or may not be caused by a memory leak in one of the applications you’re running.
1 Like
It is mostly CPU that goes up by a lot. RAM for me usually about 70%, altho when it really gets bad it goes up to 90% too.
What DE are you using? It’s usually possible to identify the culprit with htop.
I am using XFCE. Ok how should I diagnose it? EOS has glances preinstalled and I am using that usually, but I would try htop too if you tell me how to diagnose it. At the moment it is working fine tho, I should wait to do it when this happened again.
Diagnosing cpu usage is quite straightforward, really. It involves some fairly simple detective work, that’s all.
First, you need to obtain a general idea of the processes that are using the most CPU at a given point in time. You can do this by launching htop in a terminal and then sort the list by CPU usage. Htop uses ncurses, which means you can do this by clicking the top of the title bar.
Once you’ve sorted the list, observe the processes at the top of the list and take note of their process ids.
After that, you’re ready to do a more detailed analysis on each of those processes. You can do this with a simple tool called pidstat.
For example, let’s say you noticed that the process with pid 1234 keeps jumping to the top of your htop list. To observe the average cpu usage of process 1234, you can run
$ pidstat 2 -u -p 1234
What this does is that it will print out the CPU usage for process 1234 in 2 second intervals until you kill the program with Ctrl+C. When you kill the program, the program will print out the average CPU usage for that process over that period of time the program was running.
2 Likes
Sorry for late reply, I was afk. Thanks for great advise. I looked a bit at htop and it seems like it has a lot of info and it is much more user friendlier than glances. I should play about more with it to find the issue.