[SOLVED] Finding out the process(es) hogging the memory

Kardell · 2025-08-10 01:57:59

Hi All,
This is the n-th time this application kills my system.
Out of hours this app goes bonkers.
I just have tons of these entries in the journal

Aug 10 01:58:33 system earlyoom[1147]: kill_release: pid=147050: process_mrelease pidfd=4 success
Aug 10 01:58:33 system earlyoom[1147]: process 147050 exited after 0.100 seconds
Aug 10 01:58:33 system earlyoom[1147]: mem avail:  1246 of 109606 MiB ( 1.14%), swap free:    0 of 131999 MiB ( 0.00%)
Aug 10 01:58:33 system earlyoom[1147]: low memory! at or below SIGKILL limits: mem  5.00%, swap  2.50%
Aug 10 01:58:33 system earlyoom[1147]: sending SIGKILL to process 147071 uid 1000 "ZoomWebviewHost": oom_score 866, VmRSS 166 MiB, cmdline "/opt/zoom/ZoomWebviewHost --type=renderer --enable-crash-reporter>
Aug 10 01:58:33 system earlyoom[1147]: kill_release: pid=147071: process_mrelease pidfd=4 success
Aug 10 01:58:33 system earlyoom[1147]: process 147071 exited after 0.100 seconds
Aug 10 01:58:33 system earlyoom[1147]: mem avail:  1080 of 109420 MiB ( 0.99%), swap free:    0 of 131999 MiB ( 0.00%)

It keeps spinning up new instances of ZoomWebviewHost.
Most options I don't use have been disabled on the Zoom's server side (features including the AI spying) but this didn't help.
I keep updating it to the latest hoping these bugs will go away but they don't.
On the other hand this app grew from like under 100MB to like 800MB in size, I reckon tons of spying features.

I can see it took it over 5 hours of back and forth with earlyoom but it looks like it was leaking memory for more than a day.
Perhaps this crapp should go into it's own container.

Anyone having issues with this "ZoomWebviewHost"?
Please advise.
Thanks

Last edited by Kardell (2025-08-11 13:42:36)

seth · 2025-08-10 07:17:54

"VmRSS 166 MiB" - are you sure *that* is what's hogging your RAM? You have 108GB RAM and 128GB swap…

Have you actually monitored process memory consumption in *top and /proc/meminfo to see what abuses your RAM or whether you've unaccounted pages (kernel memory leak, AMDGPU is prone-ish to that through gart/gtt, possibly not a real leak)?

cryptearth · 2025-08-10 11:02:31

how do you even end up with 108gb ram? even when consider vram sharing with some igpu this would mean 20gb shared of full 128gb - and from 96gb up thats +12gb - which is not a common size either *confused
but yea - what seth wrote: your system is running out of physical ram and instead of swapping the kernel starts killing processes
stupid question: when was the last full system update and hard reboot?

seth · 2025-08-10 12:55:19

12=8+4

I think the OP is aware of the OOM condition - the question is: is something w/ an RSS of 166MB really the cause when you're facing almost 236GB total use…

Kardell · 2025-08-10 17:21:13

Hi again Gents, thanks for coming back to me.
I am going to keep an eye on the memory usage. I have Grafana running with all the stats.
To get a better context this system runs 247, full system update every 3-4 weeks followed by a reboot.
I use Zoom since I remember (~9 years) and only for the last 6 months I started having these memory issues when the OS cannot last up to the scheduled monthly update and reboot and fails every other week or more often.
I blamed ZoomWebviewHost because it is the second time I see OOM going in circles with this one.

This activity from 11:30pm isn't me. I left the desk at about 7pm but it looks like I have set something up, a time bomb at 6:30pm before I left.

Some time ago I have added a cron job to kill all the browsers every few hours so there are no tabs using up memory and CPU cycles for no reason but the available memory slowly trickles down anyway.
I reckon now I have to identify other apps that hog memory.

Last edited by Kardell (2025-08-11 13:16:57)

seth · 2025-08-10 19:02:25

This activity from 11:30pm isn't me.

A lot of cron jobs / systemd timers will run around midnight (mandb, file indexers, …)

Kardell · 2025-08-10 23:07:14

from what I can see the system already run out of memory hours before the incident.
What happened later was just a war of attrition between many processes.
I reckon unlike other processes earlyoom can kill it cannot kill ZoomWebviewHost once and for all as ZoomWebviewHost spins up another instance of itself while the old instance does not release the memory?

What I do is watch top 15 processes and eventually spot which one is leaking memory:

watch -n 2 'ps aux --sort=-%mem | awk '\''BEGIN{total_procs=0; total_mem=0} NR==1{print "Total Processes: " (NR-1) "  |  Total Memory Used: 0.0 MB"; print ""; print "USER       PID    %MEM   MEM(MB)  COMMAND"} NR>1{total_procs++; total_mem+=$6/1024; if(NR<=15) printf "%-10s %-6s %-6s %-8.1f %s\n", $1, $2, $4, $6/1024, $11} END{print ""; printf "Total Processes: %d  |  Total Memory Used: %.1f MB\n", total_procs, total_mem}'\'''

Last edited by Kardell (2025-08-11 13:42:06)

Kardell · 2025-08-21 17:00:51

I wonder why earlyoom did not terminate the RAM hungry processes but instead went after Zoom?
Do you think I should use systemd-oomd or nohang instead?

seth · 2025-08-21 20:47:18

earlyom claims to kill the process w/ the highest https://man.archlinux.org/man/core/man- … score.5.en (which would be the general OOM killing approach)
I've not read it but assume https://last9.io/blog/understanding-the … om-killer/ might reasonably break this down.

Have you identified the mem-hogger then? What was it?

Kardell · 2025-08-22 08:16:06

seth wrote:

earlyom claims to kill the process w/ the highest https://man.archlinux.org/man/core/man- … score.5.en (which would be the general OOM killing approach)
I've not read it but assume https://last9.io/blog/understanding-the … om-killer/ might reasonably break this down.
Have you identified the mem-hogger then? What was it?

I have looked into the oom_score and

The basis for this score is the amount of memory used by the process, with increases (+) or decreases (-) for factors including:
• whether the process is privileged (-). IS IT? I DON'T THINK SO
Before Linux 2.6.36 the following factors were also used in the calculation of oom_score:
• whether the process creates a lot of children using fork(2) (+); IT DOES NOT
• whether the process has been running a long time, or has used a lot of CPU time (-); APPLICABLE
• whether the process has a low nice value (i.e., > 0) (+); and I DON'T KNOW?
• whether the process is making direct hardware access (-).IS IT? I DON'T THINK SO

in this case the offenders are multiple instances of VLC left behind.

It looks like some criteria are met but not enough to kill them.
In this case the processes ran for a long time and used a lot of memory but I don't think use much of CPU while left in the background.

Last edited by Kardell (2025-08-22 08:17:31)

seth · 2025-08-22 18:56:23

in this case the offenders are multiple instances of VLC left behind

Do they have a low oom_score? Or are they ("why are there multiple vlc processes") zombified or in "D" state (waiting for IO and not porperly killable)?

Kardell · 2025-08-27 18:06:27

seth wrote:

in this case the offenders are multiple instances of VLC left behind
Do they have a low oom_score? Or are they ("why are there multiple vlc processes") zombified or in "D" state (waiting for IO and not porperly killable)?

Ok as a test I left some instances of VLC running in the background for some time.
There is one instance that grew to like 12GB of RAM usage the others I spun up later got at about 7GB each.

The interesting thing the oom_score on them is much lower than on other apps.
I can see the browser tabs and Zoom is listed with a higher OOM score (867, 866) comparing to VLC which is at 839.
The state of the VLC processes is showing as S - Sleeping.

Thank you

Arch Linux

#1 2025-08-10 01:57:59

[SOLVED] Finding out the process(es) hogging the memory

#2 2025-08-10 07:17:54

Re: [SOLVED] Finding out the process(es) hogging the memory

#3 2025-08-10 11:02:31

Re: [SOLVED] Finding out the process(es) hogging the memory

#4 2025-08-10 12:55:19

Re: [SOLVED] Finding out the process(es) hogging the memory

#5 2025-08-10 17:21:13

Re: [SOLVED] Finding out the process(es) hogging the memory

#6 2025-08-10 19:02:25

Re: [SOLVED] Finding out the process(es) hogging the memory

#7 2025-08-10 23:07:14

Re: [SOLVED] Finding out the process(es) hogging the memory

#8 2025-08-21 17:00:51

Re: [SOLVED] Finding out the process(es) hogging the memory

#9 2025-08-21 20:47:18

Re: [SOLVED] Finding out the process(es) hogging the memory

#10 2025-08-22 08:16:06

Re: [SOLVED] Finding out the process(es) hogging the memory

#11 2025-08-22 18:56:23

Re: [SOLVED] Finding out the process(es) hogging the memory

#12 2025-08-27 18:06:27

Re: [SOLVED] Finding out the process(es) hogging the memory

Board footer