Re: Isolated Web Co Session crash Firefox-ESR
On Wed, Dec 06, 2023 at 09:27:06PM +0700, Max Nikulin wrote: > On 06/12/2023 12:04, to...@tuxteam.de wrote: > > On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote: > > > > > > sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' > > > > > > Sadly it looks like I'll need to do this daily, > > > > See /etc/sysctl.conf and /etc/sysctl.conf.d if you want to make such things > > persistent. > > This particular one can not be made persistent. Writing to this file causes > kernel action. D'oh, thanks. Sorry for the confusion. Cheers -- t signature.asc Description: PGP signature
Re: Isolated Web Co Session crash Firefox-ESR
On 06/12/2023 01:42, jeremy ardley wrote: I have discovered a magic bullet for solving running out of memory sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' Sadly it looks like I'll need to do this daily, simply for using Debian Bookworm with a variety of web browsers Magic does not work. From my point of view, the scope of such command is benchmarking of cold start in some applications. It ensures that all files are read from disk, not taken from RAM caches. The command certainly may change numbers presented by free(1) or top(1). Actually if it can increase amount of free memory then applications should not starve from insufficient RAM. Kernel should drop some caches in response to memory allocation request. Probable negative consequence is that some files will be read again. You mentioned that you have no swap on this machine (I remember, actually swap exists). Does it mean that you followed some guide trying to optimize system performance e.g. to minimize SSD wearing? I suspect that changing some kernel tunables may degrade cache performance. I would try to start from clean state. Unfortunately my experience with such optimizing is negligible.
Re: Isolated Web Co Session crash Firefox-ESR
On 06/12/2023 12:04, to...@tuxteam.de wrote: On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote: sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' Sadly it looks like I'll need to do this daily, See /etc/sysctl.conf and /etc/sysctl.conf.d if you want to make such things persistent. This particular one can not be made persistent. Writing to this file causes kernel action. https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html#drop-caches However I am in doubt if it may be useful for the issue with browsers.
Re: Isolated Web Co Session crash Firefox-ESR
Karl Vogel wrote: > On Wed, Dec 06, 2023 at 06:04:36AM +0100, to...@tuxteam.de wrote: > > On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote: > > > > > I have discovered a magic bullet for solving running out of memory > > > sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' > > > Sadly it looks like I'll need to do this daily, > > > > It's the browsers eating your memory. That's what they do. > > I've had problems with Firefox eating my swap on both Linux and > FreeBSD. My fix has been to run the swap2ram script below hourly. TBF FF has stopped eating memory & swap since it updated to 115.5.0 ESR
Re: Isolated Web Co Session crash Firefox-ESR
On Wed, Dec 06, 2023 at 06:04:36AM +0100, to...@tuxteam.de wrote:
> On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote:
>
> > I have discovered a magic bullet for solving running out of memory
> > sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> > Sadly it looks like I'll need to do this daily,
>
> It's the browsers eating your memory. That's what they do.
I've had problems with Firefox eating my swap on both Linux and FreeBSD.
My fix has been to run the swap2ram script below hourly.
--
Karl Vogel I don't speak for anyone but myself
Constipational carry.
--NY Post 28 Nov "Suspect found hiding handgun in his rectum" comment #4
# --
#!/bin/ksh
# /dev/null
case "$?" in
0) ;;
*) die "You must be root to $action this." ;;
esac
}
# Make sure we have permission and a safe tempfile.
needroot
systype=$(uname -s | tr A-Z a-z)
tmp=$(mktemp -q "/tmp/$tag.XX")
case "$?" in
0) test -f "$tmp" || die "$tmp: tempfile not created" ;;
*) die "$tmp: mktemp failed" ;;
esac
# Real work starts here. Check for OS-specific instructions.
case "$systype" in
freebsd)
( swapoff -a && swapon -a ) >> $tmp 2>&1
;;
linux)
mem=$(free | awk '/Mem:/ {print $4}')
swap=$(free | awk '/Swap:/ {print $3}')
if test "$mem" -lt "$swap"; then
logmsg "not enough RAM to recover swap, nothing done"
else
( swapoff -a && swapon -a ) >> $tmp 2>&1
fi
;;
esac
# Cleanup.
test -s "$tmp" && logfile $tmp
rm $tmp
exit 0
Re: Isolated Web Co Session crash Firefox-ESR
On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote: [...] > I have discovered a magic bullet for solving running out of memory > > sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' > > Sadly it looks like I'll need to do this daily, See /etc/sysctl.conf and /etc/sysctl.conf.d if you want to make such things persistent. > simply for using Debian Bookworm with a variety of web browsers You got that order of things backwards. It's the browsers eating your memory. That's what they do. Ad industry always comes up with ways to use up your resources. Cheers -- t signature.asc Description: PGP signature
Re: Isolated Web Co Session crash Firefox-ESR
On 4/12/23 10:26, Max Nikulin wrote:
On 03/12/2023 13:33, jeremy ardley wrote:
On 3/12/23 13:59, Phil Wyett wrote:
What type of content is generally being viewed/used in firefox?
A lot of video and otherwise news and search and GPT4
---
I am curious if this creature may provide a summary on user-space OOM
killers. I have never tried them, but I expect that they may be more
intelligent than the kernel-space one. I have seen mentions of the
following ones: earlyoom, nohang, oomd.
Do you have AI browser extensions that may load huge models in respect
to memory footprint?
When the system starts to become sluggish, have you looked at the
firefox 'Task Manager' under tools to see if anything stands out?
Previously I have seen the Isolated Web Co processes maxing CPU and
the CPU fans starting to roar. Nothing unusual in content at the time
and if I kill all ESR related processes it quiets down and I can
resume the closed windows and tabs at much reduced CPU
It is just a process that is responsible for some web pages.
JavaScript loaded for particular sites may leak. Videos may consume
RAM as well. I would not rely too much on ability of an application to
recover after killing of its specific processes. From my point of view
it is better to restart Firefox in such cases.
Perhaps it is possible to find a particular site that causes issues,
but you need to inspect system namely when it is becoming sluggish.
Firefox has the about:processes and about:performance tools. They may
be accessed from the about:about list.
Try to sort top(1) output by memory ("M" key), try df(1) to check
tmpfs usage for the case that enough temporary video files are stored
there.
I believed that 32G of RAM is still above that "average" users have,
so it should be enough. Other suggestions surprised me that 0.5G of
swap may significantly change anything since it is less than 2% of RAM.
I have discovered a magic bullet for solving running out of memory
sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
Sadly it looks like I'll need to do this daily, simply for using Debian
Bookworm with a variety of web browsers
Re: Isolated Web Co Session crash Firefox-ESR
On 4/12/23 10:49, Max Nikulin wrote: On 04/12/2023 09:39, jeremy ardley wrote: I think I've found a potential culprit using about:processes https://openai.com 110% CPU I would try it in chromium. Some sites relies on optimizations implemented in its JavaScript engine. My observation is that Firefox may be CPU hungry due to "loading" animations (CSS and others). Curiously it may happen namely when JS is disabled since otherwise animated placeholders are replaced by dynamically loaded content that is still. I have also been monitoring global memory use. The last entry below is after I closed the openai tab I have not used atop, but a colleague recommended it. This tool may write logs. I installed atop and moved the openai page to Google Chrome. Free memory reported by atop hovers around 10G and doesn't seem to vary much over the past day. I put a query into gpt4 Can Chrony serve as LAN's master? Chrome CPU varied between 35% and 65% for the duration of the query of about 15 to 20 seconds. This is surprising as I thought openai GPT was implemented as an API call with minimal browser involvement.
Re: Isolated Web Co Session crash Firefox-ESR
On 04/12/2023 09:39, jeremy ardley wrote: I think I've found a potential culprit using about:processes https://openai.com 110% CPU I would try it in chromium. Some sites relies on optimizations implemented in its JavaScript engine. My observation is that Firefox may be CPU hungry due to "loading" animations (CSS and others). Curiously it may happen namely when JS is disabled since otherwise animated placeholders are replaced by dynamically loaded content that is still. I have also been monitoring global memory use. The last entry below is after I closed the openai tab I have not used atop, but a colleague recommended it. This tool may write logs.
Re: Isolated Web Co Session crash Firefox-ESR
On 4/12/23 10:26, Max Nikulin wrote: > I am curious if this creature may provide a summary on user-space OOM > killers. I have never tried them, but I expect that they may be more > intelligent than the kernel-space one. I have seen mentions of the > following ones: earlyoom, nohang, oomd. I think I've found a potential culprit using about:processes https://openai.com 110% CPU (That's GPT4) Firefox at this time is running around 1GB memory The super high CPU for openai is certainly a whole bunch of javascript. I closed that tab and the CPU load dropped to normal. Reloading the openai website and CPU oscillated between 1% and 20% till it settled around 1% I have also been monitoring global memory use. The last entry below is after I closed the openai tab root@client:~# date; free -m Mon 04 Dec 2023 09:14:29 AWST total used free shared buff/cache available Mem: 32023 12400 10521 426 10136 19622 Swap: 976 8 968 root@client:~# date; free -m Mon 04 Dec 2023 10:04:56 AWST total used free shared buff/cache available Mem: 32023 12913 9959 437 10197 19110 Swap: 976 8 968 root@client:~# date; free -m Mon 04 Dec 2023 10:28:19 AWST total used free shared buff/cache available Mem: 32023 13113 9732 419 10206 18910 Swap: 976 8 968 root@client:~# date; free -m Mon 04 Dec 2023 10:32:58 AWST total used free shared buff/cache available Mem: 32023 12545 10297 428 10217 19478 Swap: 976 8 968 This does not explain the OOM problem, but it seems memory is slowly being consumed at a rate where in 24 hours I'll start seeing problems again.
Re: Isolated Web Co Session crash Firefox-ESR
On 03/12/2023 13:33, jeremy ardley wrote:
On 3/12/23 13:59, Phil Wyett wrote:
What type of content is generally being viewed/used in firefox?
A lot of video and otherwise news and search and GPT4
---
I am curious if this creature may provide a summary on user-space OOM
killers. I have never tried them, but I expect that they may be more
intelligent than the kernel-space one. I have seen mentions of the
following ones: earlyoom, nohang, oomd.
Do you have AI browser extensions that may load huge models in respect
to memory footprint?
When the system starts to become sluggish, have you looked at the
firefox 'Task Manager' under tools to see if anything stands out?
Previously I have seen the Isolated Web Co processes maxing CPU and the
CPU fans starting to roar. Nothing unusual in content at the time and if
I kill all ESR related processes it quiets down and I can resume the
closed windows and tabs at much reduced CPU
It is just a process that is responsible for some web pages. JavaScript
loaded for particular sites may leak. Videos may consume RAM as well. I
would not rely too much on ability of an application to recover after
killing of its specific processes. From my point of view it is better to
restart Firefox in such cases.
Perhaps it is possible to find a particular site that causes issues, but
you need to inspect system namely when it is becoming sluggish.
Firefox has the about:processes and about:performance tools. They may be
accessed from the about:about list.
Try to sort top(1) output by memory ("M" key), try df(1) to check tmpfs
usage for the case that enough temporary video files are stored there.
I believed that 32G of RAM is still above that "average" users have, so
it should be enough. Other suggestions surprised me that 0.5G of swap
may significantly change anything since it is less than 2% of RAM.
Re: Isolated Web Co Session crash Firefox-ESR
On 12/3/23 01:00, jeremy ardley wrote: On 3/12/23 15:37, Phil Wyett wrote: Not to regurgitating info here, I will add a link below that will instruct how to adjust or disable oom-killer in a sensible manner if you wish to experiment (your choice and being cautious :-)) if it is in fact the oom-killer algorithm that is the main cause of your issue. The top output provided earlier seems to show nearly a gigabyte of swap, a tiny part of it used. You are right, though, that adding swap will not improve matters for long. A small amount of swap probably is a good idea to take care of occasional memory overcommitment. But on an interactive system, swap thrashing that may happen with a (or several) greedy enough processes will kill performance for everything that matters, and if one or more of them is leaking memory, adding swap (or even more memory) will only delay the collapse. As a reference point Isolated Web Co is an occasional annoyance here on machines with well over 64G memory. I kill it without mercy when it appears to be causing swap. Regards, Tom Dial The issue is not so much Isolated Web Co being terminated, but my entire Mate session being terminated. I wouldn't have too much problem if OOM-killer hit Firefox. I have done it myself when things got slow. However, I can't see any valid reason for the Mate session to be assassinated? Or at least be inevitable collateral damage.
Re: Isolated Web Co Session crash Firefox-ESR
On 4/12/23 06:08, Michael Kjörling wrote: The reason for the system slowing down seems to me to likely be that once the system comes under memory pressure (quite possibly due to an increase in anonymous pages), it must evict something, and only non-anonymous (that is, backed) pages can be evicted safely. So most likely the allocator starts evicting program code, because that can be read back from storage later, or other forms of cache, in order to keep room for the anonymous pages which it cannot evict. The next time that code is needed, it must go all the way to the (horribly slow by comparison) storage, instead of originally just writing out to swap some anonymous pages which haven't been used in comparatively forever, like a tmpfs that someone mentioned, or data for inactive web browser tabs or documents you aren't doing anything active with. It turns out I actually do have a modest swap though I don't recall enabling it. It doesn't seem to be used anway. Given that, the system after 24 hours of typical use is nowhere near using up most of the memory. I expect that the web browsers keep an eye on available memory and do most of their memory management/caching in a 'fixed' allocation as well as the memory marked buff/cache Here is the status just now root@client:~# free -m totalusedfree shared buff/cache available Mem: 320239654 14053 3369261 22369 Swap:976 8 968
Re: Isolated Web Co Session crash Firefox-ESR
On 3 Dec 2023 14:33 +0800, from jeremy.ard...@gmail.com (jeremy ardley): >> You have swap and it is enabled? > > No Swap. I prefer not on SSD Why not? You are definitely putting the VM allocator in a much more difficult spot than necessary by not providing any swap space. If I read what you provided in a different message in this thread correctly, over half of your RAM at that particular time was being used for anonymous pages; that is, data which has no backing on other storage, and therefore cannot be evicted from virtual memory. Combine this with the fact that you have no swap, and all that data _must_ be kept in RAM because that's all there is. Combine _that_ with running several rather memory-hungry processes (several web browsers plus LibreOffice) _and_ the Linux default of allowing memory overcommitting, and I'm not all that surprised that you're apparently hitting the OOM killer from time to time. The reason for the system slowing down seems to me to likely be that once the system comes under memory pressure (quite possibly due to an increase in anonymous pages), it must evict something, and only non-anonymous (that is, backed) pages can be evicted safely. So most likely the allocator starts evicting program code, because that can be read back from storage later, or other forms of cache, in order to keep room for the anonymous pages which it cannot evict. The next time that code is needed, it must go all the way to the (horribly slow by comparison) storage, instead of originally just writing out to swap some anonymous pages which haven't been used in comparatively forever, like a tmpfs that someone mentioned, or data for inactive web browser tabs or documents you aren't doing anything active with. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Isolated Web Co Session crash Firefox-ESR
Hi. On Sun, Dec 03, 2023 at 12:58:47PM +0800, jeremy ardley wrote: > I noticed my Firefox -esr browser becoming progressively more sluggish. Then > suddenly I was back to the system login screen > > This is not the first time this has happened although previously when it > started getting sluggish I killed all Firefox related process > > System logs show the start of the event. > > 2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] Isolated Web > Co invoked oom-killer: > gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, > oom_score_adj=100 Tail of that particular trace always shows top memory consumers at the very moment oom-killer was invoked. Skipping that information can and will lead to guessing. And in this particular case: > inactive_anon:29781756kB > anon_thp: 17088512kB Do you have any relatively large filesystem, such as /tmp, mounted as tmpfs? Any tmpfs contents are not accounted by free(1) or top(1), but using large tmpfs with small swap can lead to funny results to say the least. Reco
Re: Isolated Web Co Session crash Firefox-ESR
On Sun, Dec 3, 2023 at 6:21 AM jeremy ardley wrote: > > On 3/12/23 13:59, Phil Wyett wrote: > > Your system RAM total is? > > 32G You might also want to try compressed memory, like zram. > > You have swap and it is enabled? > > No Swap. I prefer not on SSD In this configuration, you may want to set `vm.overcommit_memory = 2` since there is no page file. I don't think it will make the OOM go away, but it will set a policy more in line with what you are doing. (It may move the OOM from some random program to the browser, since the browser is grabbing large amounts of memory). But I would use a swap file, and set `vm.swappiness = 1`. That tells the OS to do just about everything except use the swap file. I use this for all my dev boards with SDcards. The swap file is needed because the dev boards often lack resources, like having 512 MB of RAM. (In my case, I need to run a C++ compiler, so I have to have a swap file or accept the Denial of Service and not get my work done). Jeff
Re: Isolated Web Co Session crash Firefox-ESR
On Sun, 2023-12-03 at 16:00 +0800, jeremy ardley wrote: > > On 3/12/23 15:37, Phil Wyett wrote: > > Not to regurgitating info here, I will add a link below that will > > instruct how to adjust or disable oom-killer in a sensible manner if > > you wish to experiment (your choice and being cautious :-)) if it is > > in fact the oom-killer algorithm that is the main cause of your issue. > > > The issue is not so much Isolated Web Co being terminated, but my entire > Mate session being terminated. > > I wouldn't have too much problem if OOM-killer hit Firefox. I have done > it myself when things got slow. > > However, I can't see any valid reason for the Mate session to be > assassinated? Or at least be inevitable collateral damage. > Hi, Not being deeply familiar with the oom-killer heuristics, I could not offer reasoning why 'mate' is killed. These heuristics by default kill the most memory hogging processes in theory and the consequences of this on other processes I cannot comment on. There is one setting you may wish look at and consider. Reading: https://docs.kernel.org/admin-guide/sysctl/vm.html I see the following: https://docs.kernel.org/admin-guide/sysctl/vm.html?highlight=laptop#oom-kill-allocating-task Setting this to '1' may trigger a strategy that does not put 'mate' in the firing line as it changes the target for killing to the process call that triggers the out of memory condition. I am sure if my reading of this setting is wrong, someone will correct. This would be done of course at your own risk after doing the research yourself. Regards Phil -- Playing the game for the games sake. Web: * Debian Wiki: https://wiki.debian.org/PhilWyett * Website: https://kathenas.org signature.asc Description: This is a digitally signed message part
Re: Isolated Web Co Session crash Firefox-ESR
On Sun, 2023-12-03 at 14:59 +0800, jeremy ardley wrote: > > On 3/12/23 14:46, Phil Wyett wrote: > > The first thing I would do before any other is to enable swap and see > > what benefits that brings. I have no production laptop or desktop > > (laptop with 32G being daily driver with NVME (root) and an SSD (home) > > drive inside) that does not have swap. I have 8G of swap on my laptop > > and it does get used by the system, but only in low amounts. Others > > may have other strategies here, but this is where I would start. > > > I don't think it is actually a lack of memory. What I do see is all the > web browsers are up there on CPU along with nvidia-modeset. > > Putting in swap may delay the time things start going awry but the cause > won't be lack of memory > > top CPU > > top - 14:55:15 up 44 days, 41 min, 1 user, load average: 0.19, 0.19, 0.19 > Tasks: 386 total, 1 running, 385 sleeping, 0 stopped, 0 zombie > %Cpu(s): 0.6 us, 0.2 sy, 0.0 ni, 99.1 id, 0.1 wa, 0.0 hi, 0.0 si, > 0.0 st > MiB Mem : 32023.4 total, 19201.2 free, 7118.7 used, 6564.6 buff/cache > MiB Swap: 977.0 total, 968.1 free, 8.9 used. 24904.6 avail Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3433245 jeremy 20 0 2584752 210788 100352 S 4.3 0.6 0:25.77 > Isolated Web Co > 3423627 jeremy 20 0 1140.1g 326428 130228 S 2.6 1.0 6:12.36 chrome > 3423253 jeremy 20 0 32.9g 387804 299712 S 1.0 1.2 2:25.86 chrome > 723 root 20 0 0 0 0 S 0.7 0.0 269:07.26 > nvidia-modeset/kthread_q > 3432484 jeremy 20 0 3689468 688004 243920 S 0.7 2.1 1:01.72 > firefox-esr > 3433214 root 20 0 11880 5348 3196 R 0.7 0.0 0:03.16 top > 3422887 jeremy 20 0 697716 55924 40800 S 0.3 0.2 0:07.98 > mate-terminal > 3423206 jeremy 20 0 32.8g 434756 252740 S 0.3 1.3 1:32.29 chrome > 3423254 jeremy 20 0 32.4g 129252 101388 S 0.3 0.4 0:28.83 chrome > 3428534 jeremy 20 0 32.6g 480104 145044 S 0.3 1.5 2:43.60 > chromium > 3428658 jeremy 20 0 1134.0g 212384 117084 S 0.3 0.6 7:09.41 > chromium > 1 root 20 0 168800 10412 6324 S 0.0 0.0 0:45.56 > systemd > 2 root 20 0 0 0 0 S 0.0 0.0 0:01.82 > kthreadd > 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 > rcu_gp > 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 > rcu_par_gp > 5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 > slub_flushwq > 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns > 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 > kworker/0:0H-events_highpri > > > top memory > > top - 14:58:34 up 44 days, 45 min, 1 user, load average: 0.27, 0.23, 0.20 > Tasks: 384 total, 3 running, 381 sleeping, 0 stopped, 0 zombie > %Cpu(s): 0.8 us, 0.4 sy, 0.0 ni, 98.7 id, 0.1 wa, 0.0 hi, 0.1 si, > 0.0 st > MiB Mem : 32023.4 total, 19055.2 free, 7260.6 used, 6570.2 buff/cache > MiB Swap: 977.0 total, 968.1 free, 8.9 used. 24762.8 avail Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3422963 jeremy 20 0 4032104 979264 208004 S 0.0 3.0 5:20.33 > thunderbird > 3432484 jeremy 20 0 3679780 711916 250108 S 1.3 2.2 1:13.98 > firefox-esr > 3428534 jeremy 20 0 32.6g 480364 144980 R 1.7 1.5 2:46.34 > chromium > 3423206 jeremy 20 0 32.8g 434600 252740 S 0.0 1.3 1:32.66 chrome > 3422183 root 20 0 25.0g 419692 139016 S 0.3 1.3 0:47.61 Xorg > 3423253 jeremy 20 0 32.9g 387540 299712 S 1.3 1.2 2:28.33 chrome > 1750 jeremy 20 0 1163816 380224 9776 S 0.0 1.2 3:53.92 > goa-daemon > 3423627 jeremy 20 0 1140.1g 326700 130228 S 3.6 1.0 6:19.81 chrome > 3422581 jeremy 20 0 7293420 311912 78012 S 0.3 1.0 0:40.50 > dropbox > 3423600 jeremy 20 0 1134.1g 294804 128548 S 0.0 0.9 0:46.53 chrome > 3428484 jeremy 20 0 32.7g 266044 192084 S 0.3 0.8 0:38.63 > chromium > 2320 jeremy 20 0 1752388 244220 12876 S 0.0 0.7 7:20.61 > evolution-calen > 3433245 jeremy 20 0 2584752 212408 100480 S 0.0 0.6 0:32.45 > Isolated Web Co > 1664 jeremy 9 -11 240828 203652 5716 S 0.0 0.6 7,25 > pipewire-pulse > 3433581 jeremy 20 0 296 201664 98504 S 0.7 0.6 0:03.09 > Isolated Web Co > 3428658 jeremy 20 0 1134.0g 200140 117084 R 4.3 0.6 7:18.18 > chromium > 3432583 jeremy 20 0 18.7g 191500 108380 S 0.3 0.6 0:10.79 > WebExtensions > 3433289 jeremy 20 0 2549968 181504 97876 S 0.0 0.6 0:03.47 > Isolated Web Co > 3422461 jeremy 20 0 1385296 158252 94932 S 0.0 0.5 0:20.50 > nextcloud > 3428536 jeremy 20 0 32.4g 152468 132780 S 0.3 0.5 0:19.69 > chromium > 3432350 jeremy 20 0 1134.0g
Re: Isolated Web Co Session crash Firefox-ESR
On 3/12/23 15:37, Phil Wyett wrote: Not to regurgitating info here, I will add a link below that will instruct how to adjust or disable oom-killer in a sensible manner if you wish to experiment (your choice and being cautious :-)) if it is in fact the oom-killer algorithm that is the main cause of your issue. The issue is not so much Isolated Web Co being terminated, but my entire Mate session being terminated. I wouldn't have too much problem if OOM-killer hit Firefox. I have done it myself when things got slow. However, I can't see any valid reason for the Mate session to be assassinated? Or at least be inevitable collateral damage.
Re: Isolated Web Co Session crash Firefox-ESR
On 12/2/23 20:58, jeremy ardley wrote: I noticed my Firefox -esr browser becoming progressively more sluggish. Then suddenly I was back to the system login screen This is not the first time this has happened although previously when it started getting sluggish I killed all Firefox related process System logs show the start of the event. 2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] Isolated Web Co invoked oom-killer: gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, oom_score_adj=100 On 12/2/23 22:33, jeremy ardley wrote: On 3/12/23 13:59, Phil Wyett wrote: Your system RAM total is? 32G You have swap and it is enabled? No Swap. I prefer not on SSD What Desktop Environment (DE) are you using - GNOME, KDE etc.? Mate with multiple panels. How many apps would you normally be running on the system at once? 3 x web browsers Firefox - multiple windows, Chrome one window, Chromium one window Intermittently mate terminals and LibreOffice applications How many extensions have you installed/running in firefox? Several. All the usual blockers plus bypass paywalls clean and Multi Account Containers How many tabs would you normally have open? In firefox, perhaps 20 over two windows What type of content is generally being viewed/used in firefox? A lot of video and otherwise news and search and GPT4 When the system starts to become sluggish, have you looked at the firefox 'Task Manager' under tools to see if anything stands out? Previously I have seen the Isolated Web Co processes maxing CPU and the CPU fans starting to roar. Nothing unusual in content at the time and if I kill all ESR related processes it quiets down and I can resume the closed windows and tabs at much reduced CPU It's obvious the main culprit is Firefox-ESR and the Isolated Web Co processes. What triggers it other than elapsed time I have no idea On 12/2/23 22:59, jeremy ardley wrote: I don't think it is actually a lack of memory. What I do see is all the web browsers are up there on CPU along with nvidia-modeset. Putting in swap may delay the time things start going awry but the cause won't be lack of memory I tried running a Debian desktop without swap and encountered the same symptom -- crashed desktop and return to login screen. The solution was two-fold: 1. Provision 1 GB of swap. 2. Add Xfce panel widgets so that I can see what is going on. Between the two, I usually have enough time to kill problem apps before a crash. And, more memory would not hurt. David
Re: Isolated Web Co Session crash Firefox-ESR
On Sun, 2023-12-03 at 14:59 +0800, jeremy ardley wrote: > > On 3/12/23 14:46, Phil Wyett wrote: > > The first thing I would do before any other is to enable swap and see > > what benefits that brings. I have no production laptop or desktop > > (laptop with 32G being daily driver with NVME (root) and an SSD (home) > > drive inside) that does not have swap. I have 8G of swap on my laptop > > and it does get used by the system, but only in low amounts. Others > > may have other strategies here, but this is where I would start. > > > I don't think it is actually a lack of memory. What I do see is all the > web browsers are up there on CPU along with nvidia-modeset. > > Putting in swap may delay the time things start going awry but the cause > won't be lack of memory > > top CPU > > top - 14:55:15 up 44 days, 41 min, 1 user, load average: 0.19, 0.19, 0.19 > Tasks: 386 total, 1 running, 385 sleeping, 0 stopped, 0 zombie > %Cpu(s): 0.6 us, 0.2 sy, 0.0 ni, 99.1 id, 0.1 wa, 0.0 hi, 0.0 si, > 0.0 st > MiB Mem : 32023.4 total, 19201.2 free, 7118.7 used, 6564.6 buff/cache > MiB Swap: 977.0 total, 968.1 free, 8.9 used. 24904.6 avail Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3433245 jeremy 20 0 2584752 210788 100352 S 4.3 0.6 0:25.77 > Isolated Web Co > 3423627 jeremy 20 0 1140.1g 326428 130228 S 2.6 1.0 6:12.36 chrome > 3423253 jeremy 20 0 32.9g 387804 299712 S 1.0 1.2 2:25.86 chrome > 723 root 20 0 0 0 0 S 0.7 0.0 269:07.26 > nvidia-modeset/kthread_q > 3432484 jeremy 20 0 3689468 688004 243920 S 0.7 2.1 1:01.72 > firefox-esr > 3433214 root 20 0 11880 5348 3196 R 0.7 0.0 0:03.16 top > 3422887 jeremy 20 0 697716 55924 40800 S 0.3 0.2 0:07.98 > mate-terminal > 3423206 jeremy 20 0 32.8g 434756 252740 S 0.3 1.3 1:32.29 chrome > 3423254 jeremy 20 0 32.4g 129252 101388 S 0.3 0.4 0:28.83 chrome > 3428534 jeremy 20 0 32.6g 480104 145044 S 0.3 1.5 2:43.60 > chromium > 3428658 jeremy 20 0 1134.0g 212384 117084 S 0.3 0.6 7:09.41 > chromium > 1 root 20 0 168800 10412 6324 S 0.0 0.0 0:45.56 > systemd > 2 root 20 0 0 0 0 S 0.0 0.0 0:01.82 > kthreadd > 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 > rcu_gp > 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 > rcu_par_gp > 5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 > slub_flushwq > 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns > 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 > kworker/0:0H-events_highpri > > > top memory > > top - 14:58:34 up 44 days, 45 min, 1 user, load average: 0.27, 0.23, 0.20 > Tasks: 384 total, 3 running, 381 sleeping, 0 stopped, 0 zombie > %Cpu(s): 0.8 us, 0.4 sy, 0.0 ni, 98.7 id, 0.1 wa, 0.0 hi, 0.1 si, > 0.0 st > MiB Mem : 32023.4 total, 19055.2 free, 7260.6 used, 6570.2 buff/cache > MiB Swap: 977.0 total, 968.1 free, 8.9 used. 24762.8 avail Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3422963 jeremy 20 0 4032104 979264 208004 S 0.0 3.0 5:20.33 > thunderbird > 3432484 jeremy 20 0 3679780 711916 250108 S 1.3 2.2 1:13.98 > firefox-esr > 3428534 jeremy 20 0 32.6g 480364 144980 R 1.7 1.5 2:46.34 > chromium > 3423206 jeremy 20 0 32.8g 434600 252740 S 0.0 1.3 1:32.66 chrome > 3422183 root 20 0 25.0g 419692 139016 S 0.3 1.3 0:47.61 Xorg > 3423253 jeremy 20 0 32.9g 387540 299712 S 1.3 1.2 2:28.33 chrome > 1750 jeremy 20 0 1163816 380224 9776 S 0.0 1.2 3:53.92 > goa-daemon > 3423627 jeremy 20 0 1140.1g 326700 130228 S 3.6 1.0 6:19.81 chrome > 3422581 jeremy 20 0 7293420 311912 78012 S 0.3 1.0 0:40.50 > dropbox > 3423600 jeremy 20 0 1134.1g 294804 128548 S 0.0 0.9 0:46.53 chrome > 3428484 jeremy 20 0 32.7g 266044 192084 S 0.3 0.8 0:38.63 > chromium > 2320 jeremy 20 0 1752388 244220 12876 S 0.0 0.7 7:20.61 > evolution-calen > 3433245 jeremy 20 0 2584752 212408 100480 S 0.0 0.6 0:32.45 > Isolated Web Co > 1664 jeremy 9 -11 240828 203652 5716 S 0.0 0.6 7,25 > pipewire-pulse > 3433581 jeremy 20 0 296 201664 98504 S 0.7 0.6 0:03.09 > Isolated Web Co > 3428658 jeremy 20 0 1134.0g 200140 117084 R 4.3 0.6 7:18.18 > chromium > 3432583 jeremy 20 0 18.7g 191500 108380 S 0.3 0.6 0:10.79 > WebExtensions > 3433289 jeremy 20 0 2549968 181504 97876 S 0.0 0.6 0:03.47 > Isolated Web Co > 3422461 jeremy 20 0 1385296 158252 94932 S 0.0 0.5 0:20.50 > nextcloud > 3428536 jeremy 20 0 32.4g 152468 132780 S 0.3 0.5 0:19.69 > chromium > 3432350 jeremy 20 0 1134.0g
Re: Isolated Web Co Session crash Firefox-ESR
jeremy ardley writes: > I don't think it is actually a lack of memory. What I do see is all > the web browsers are up there on CPU along with nvidia-modeset. What do you consider to be "up there"? 4.3% (your highest CPU usage in this output) hardly seems to qualify as something to be concerned about. nvidia-modeset is consuming a whopping 0.7% CPU. I assume these numbers are while the system is operating normally and not when it starts to struggle. Why do you think heavy CPU load would cause the OOM killer to activate? Some precesses just don't appreciate having no swap available.
Re: Isolated Web Co Session crash Firefox-ESR
On 3/12/23 14:46, Phil Wyett wrote: The first thing I would do before any other is to enable swap and see what benefits that brings. I have no production laptop or desktop (laptop with 32G being daily driver with NVME (root) and an SSD (home) drive inside) that does not have swap. I have 8G of swap on my laptop and it does get used by the system, but only in low amounts. Others may have other strategies here, but this is where I would start. I don't think it is actually a lack of memory. What I do see is all the web browsers are up there on CPU along with nvidia-modeset. Putting in swap may delay the time things start going awry but the cause won't be lack of memory top CPU top - 14:55:15 up 44 days, 41 min, 1 user, load average: 0.19, 0.19, 0.19 Tasks: 386 total, 1 running, 385 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.6 us, 0.2 sy, 0.0 ni, 99.1 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 32023.4 total, 19201.2 free, 7118.7 used, 6564.6 buff/cache MiB Swap: 977.0 total, 968.1 free, 8.9 used. 24904.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3433245 jeremy 20 0 2584752 210788 100352 S 4.3 0.6 0:25.77 Isolated Web Co 3423627 jeremy 20 0 1140.1g 326428 130228 S 2.6 1.0 6:12.36 chrome 3423253 jeremy 20 0 32.9g 387804 299712 S 1.0 1.2 2:25.86 chrome 723 root 20 0 0 0 0 S 0.7 0.0 269:07.26 nvidia-modeset/kthread_q 3432484 jeremy 20 0 3689468 688004 243920 S 0.7 2.1 1:01.72 firefox-esr 3433214 root 20 0 11880 5348 3196 R 0.7 0.0 0:03.16 top 3422887 jeremy 20 0 697716 55924 40800 S 0.3 0.2 0:07.98 mate-terminal 3423206 jeremy 20 0 32.8g 434756 252740 S 0.3 1.3 1:32.29 chrome 3423254 jeremy 20 0 32.4g 129252 101388 S 0.3 0.4 0:28.83 chrome 3428534 jeremy 20 0 32.6g 480104 145044 S 0.3 1.5 2:43.60 chromium 3428658 jeremy 20 0 1134.0g 212384 117084 S 0.3 0.6 7:09.41 chromium 1 root 20 0 168800 10412 6324 S 0.0 0.0 0:45.56 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:01.82 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 slub_flushwq 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-events_highpri top memory top - 14:58:34 up 44 days, 45 min, 1 user, load average: 0.27, 0.23, 0.20 Tasks: 384 total, 3 running, 381 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.8 us, 0.4 sy, 0.0 ni, 98.7 id, 0.1 wa, 0.0 hi, 0.1 si, 0.0 st MiB Mem : 32023.4 total, 19055.2 free, 7260.6 used, 6570.2 buff/cache MiB Swap: 977.0 total, 968.1 free, 8.9 used. 24762.8 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3422963 jeremy 20 0 4032104 979264 208004 S 0.0 3.0 5:20.33 thunderbird 3432484 jeremy 20 0 3679780 711916 250108 S 1.3 2.2 1:13.98 firefox-esr 3428534 jeremy 20 0 32.6g 480364 144980 R 1.7 1.5 2:46.34 chromium 3423206 jeremy 20 0 32.8g 434600 252740 S 0.0 1.3 1:32.66 chrome 3422183 root 20 0 25.0g 419692 139016 S 0.3 1.3 0:47.61 Xorg 3423253 jeremy 20 0 32.9g 387540 299712 S 1.3 1.2 2:28.33 chrome 1750 jeremy 20 0 1163816 380224 9776 S 0.0 1.2 3:53.92 goa-daemon 3423627 jeremy 20 0 1140.1g 326700 130228 S 3.6 1.0 6:19.81 chrome 3422581 jeremy 20 0 7293420 311912 78012 S 0.3 1.0 0:40.50 dropbox 3423600 jeremy 20 0 1134.1g 294804 128548 S 0.0 0.9 0:46.53 chrome 3428484 jeremy 20 0 32.7g 266044 192084 S 0.3 0.8 0:38.63 chromium 2320 jeremy 20 0 1752388 244220 12876 S 0.0 0.7 7:20.61 evolution-calen 3433245 jeremy 20 0 2584752 212408 100480 S 0.0 0.6 0:32.45 Isolated Web Co 1664 jeremy 9 -11 240828 203652 5716 S 0.0 0.6 7,25 pipewire-pulse 3433581 jeremy 20 0 296 201664 98504 S 0.7 0.6 0:03.09 Isolated Web Co 3428658 jeremy 20 0 1134.0g 200140 117084 R 4.3 0.6 7:18.18 chromium 3432583 jeremy 20 0 18.7g 191500 108380 S 0.3 0.6 0:10.79 WebExtensions 3433289 jeremy 20 0 2549968 181504 97876 S 0.0 0.6 0:03.47 Isolated Web Co 3422461 jeremy 20 0 1385296 158252 94932 S 0.0 0.5 0:20.50 nextcloud 3428536 jeremy 20 0 32.4g 152468 132780 S 0.3 0.5 0:19.69 chromium 3432350 jeremy 20 0 1134.0g 143620 103132 S 0.0 0.4 0:01.76 chrome 3423380 jeremy 20 0 1132.0g 141860 100880 S 0.0 0.4 0:03.64 chrome 3423715 jeremy 20 0 1132.0g 137276 102264 S 0.0 0.4 0:02.83 chrome 3432598 jeremy 20 0 2477752 135292 98484 S 0.0 0.4 0:02.16
Re: Isolated Web Co Session crash Firefox-ESR
On Sun, 2023-12-03 at 14:33 +0800, jeremy ardley wrote: > > On 3/12/23 13:59, Phil Wyett wrote: > > Your system RAM total is? > > 32G > > > > You have swap and it is enabled? > > No Swap. I prefer not on SSD > > > Hi, The first thing I would do before any other is to enable swap and see what benefits that brings. I have no production laptop or desktop (laptop with 32G being daily driver with NVME (root) and an SSD (home) drive inside) that does not have swap. I have 8G of swap on my laptop and it does get used by the system, but only in low amounts. Others may have other strategies here, but this is where I would start. Regards Phil -- Playing the game for the games sake. Web: * Debian Wiki: https://wiki.debian.org/PhilWyett * Website: https://kathenas.org signature.asc Description: This is a digitally signed message part
Re: Isolated Web Co Session crash Firefox-ESR
On 3/12/23 13:59, Phil Wyett wrote: Your system RAM total is? 32G You have swap and it is enabled? No Swap. I prefer not on SSD What Desktop Environment (DE) are you using - GNOME, KDE etc.? Mate with multiple panels. How many apps would you normally be running on the system at once? 3 x web browsers Firefox - multiple windows, Chrome one window, Chromium one window Intermittently mate terminals and LibreOffice applications How many extensions have you installed/running in firefox? Several. All the usual blockers plus bypass paywalls clean and Multi Account Containers How many tabs would you normally have open? In firefox, perhaps 20 over two windows What type of content is generally being viewed/used in firefox? A lot of video and otherwise news and search and GPT4 When the system starts to become sluggish, have you looked at the firefox 'Task Manager' under tools to see if anything stands out? Previously I have seen the Isolated Web Co processes maxing CPU and the CPU fans starting to roar. Nothing unusual in content at the time and if I kill all ESR related processes it quiets down and I can resume the closed windows and tabs at much reduced CPU It's obvious the main culprit is Firefox-ESR and the Isolated Web Co processes. What triggers it other than elapsed time I have no idea
Re: Isolated Web Co Session crash Firefox-ESR
On Sun, 2023-12-03 at 12:58 +0800, jeremy ardley wrote: > I noticed my Firefox -esr browser becoming progressively more sluggish. > Then suddenly I was back to the system login screen > > This is not the first time this has happened although previously when it > started getting sluggish I killed all Firefox related process > > System logs show the start of the event. > > 2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] > Isolated Web Co invoked oom-killer: > gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, > oom_score_adj=100 > 2023-12-03T11:35:03.335962+08:00 client kernel: [3792101.257078] CPU: 8 > PID: 3410924 Comm: Isolated Web Co Tainted: P OE 6.1.0-13-amd64 #1 > Debian 6.1.55-1 > 2023-12-03T11:35:03.335964+08:00 client kernel: [3792101.257081] > Hardware name: System manufacturer System Product Name/PRIME B450M-A, > BIOS 0219 06/08/2018 > 2023-12-03T11:35:03.335965+08:00 client kernel: [3792101.257082] Call Trace: > 2023-12-03T11:35:03.335966+08:00 client kernel: [3792101.257085] > 2023-12-03T11:35:03.335967+08:00 client kernel: [3792101.257088] > dump_stack_lvl+0x44/0x5c > 2023-12-03T11:35:03.335968+08:00 client kernel: [3792101.257094] > dump_header+0x4a/0x211 > 2023-12-03T11:35:03.335978+08:00 client kernel: [3792101.257097] > oom_kill_process.cold+0xb/0x10 > 2023-12-03T11:35:03.335979+08:00 client kernel: [3792101.257100] > out_of_memory+0x1fd/0x4c0 > 2023-12-03T11:35:03.335980+08:00 client kernel: [3792101.257104] > __alloc_pages_slowpath.constprop.0+0xc73/0xdc0 > 2023-12-03T11:35:03.335981+08:00 client kernel: [3792101.257108] > __alloc_pages+0x305/0x330 > 2023-12-03T11:35:03.335982+08:00 client kernel: [3792101.257111] > __folio_alloc+0x17/0x50 > 2023-12-03T11:35:03.335983+08:00 client kernel: [3792101.257113] ? > policy_node+0x51/0x70 > 2023-12-03T11:35:03.335984+08:00 client kernel: [3792101.257116] > vma_alloc_folio+0x9c/0x370 > 2023-12-03T11:35:03.335984+08:00 client kernel: [3792101.257119] > __handle_mm_fault+0x92f/0xfa0 > 2023-12-03T11:35:03.335985+08:00 client kernel: [3792101.257123] > handle_mm_fault+0xdb/0x2d0 > 2023-12-03T11:35:03.335986+08:00 client kernel: [3792101.257126] > do_user_addr_fault+0x19c/0x570 > 2023-12-03T11:35:03.335986+08:00 client kernel: [3792101.257129] > exc_page_fault+0x70/0x170 > 2023-12-03T11:35:03.335987+08:00 client kernel: [3792101.257132] > asm_exc_page_fault+0x22/0x30 > 2023-12-03T11:35:03.335987+08:00 client kernel: [3792101.257136] RIP: > 0033:0x7fcb86b0dd3a > 2023-12-03T11:35:03.335988+08:00 client kernel: [3792101.257139] Code: > 48 89 fb 48 83 ec 18 e8 b4 de ff ff 48 85 c0 74 42 48 89 c5 48 8b 43 48 > 48 3b 43 50 0f 84 5e 01 00 00 48 8d 50 08 48 89 53 48 <48> 89 28 4c 8b > bb 88 00 00 00 4d 85 ff 74 16 41 80 7f 19 00 4d 8b > 2023-12-03T11:35:03.335989+08:00 client kernel: [3792101.257140] RSP: > 002b:7ffc85877cd0 EFLAGS: 00010283 > 2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257142] RAX: > 7fcb0a3b7000 RBX: 7fcb45f33000 RCX: 05937a1b > 2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257144] RDX: > 7fcb0a3b7008 RSI: 7fcb85941410 RDI: > 2023-12-03T11:35:03.335991+08:00 client kernel: [3792101.257145] RBP: > 7fcb3ebaea08 R08: 7fcb3ebaea08 R09: 008fc63b > 2023-12-03T11:35:03.335992+08:00 client kernel: [3792101.257146] R10: > R11: 0008 R12: 0558afa25450 > 2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257147] R13: > 7ffc85877d20 R14: R15: 148e1958de08 > 2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257150] > 2023-12-03T11:35:03.335994+08:00 client kernel: [3792101.257151] Mem-Info: > 2023-12-03T11:35:03.335994+08:00 client kernel: [3792101.257152] > active_anon:202973 inactive_anon:7445439 isolated_anon:0 > 2023-12-03T11:35:03.335998+08:00 client kernel: [3792101.257152] > active_file:816 inactive_file:3360 isolated_file:0 > 2023-12-03T11:35:03.335999+08:00 client kernel: [3792101.257152] > unevictable:2092 dirty:0 writeback:0 > 2023-12-03T11:35:03.336000+08:00 client kernel: [3792101.257152] > slab_reclaimable:180435 slab_unreclaimable:80961 > 2023-12-03T11:35:03.336001+08:00 client kernel: [3792101.257152] > mapped:215565 shmem:310212 pagetables:40361 > 2023-12-03T11:35:03.336001+08:00 client kernel: [3792101.257152] > sec_pagetables:0 bounce:0 > 2023-12-03T11:35:03.336002+08:00 client kernel: [3792101.257152] > kernel_misc_reclaimable:0 > 2023-12-03T11:35:03.336004+08:00 client kernel: [3792101.257152] > free:81539 free_pcp:87 free_cma:0 > 2023-12-03T11:35:03.336004+08:00 client kernel: [3792101.257156] Node 0 > active_anon:811892kB inactive_anon:29781756kB active_file:3264kB > inactive_file:13440kB unevictable:8368kB isolated(anon):0kB > isolated(file):0kB mapped:862260kB dirty:0kB writeback:0kB > shmem:1240848kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 17088512kB > writeback_tmp:0kB
Re: Isolated Web Co Session crash Firefox-ESR
jeremy ardley writes: > I noticed my Firefox -esr browser becoming progressively more > sluggish. Then suddenly I was back to the system login screen > > This is not the first time this has happened although previously when > it started getting sluggish I killed all Firefox related process > > System logs show the start of the event. > > 2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] > Isolated Web Co invoked oom-killer: ^^ You're out of memory, the system started killing processes to keep itself alive. It tends not be particularly "smart" about what to kill.
Isolated Web Co Session crash Firefox-ESR
I noticed my Firefox -esr browser becoming progressively more sluggish. Then suddenly I was back to the system login screen This is not the first time this has happened although previously when it started getting sluggish I killed all Firefox related process System logs show the start of the event. 2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] Isolated Web Co invoked oom-killer: gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, oom_score_adj=100 2023-12-03T11:35:03.335962+08:00 client kernel: [3792101.257078] CPU: 8 PID: 3410924 Comm: Isolated Web Co Tainted: P OE 6.1.0-13-amd64 #1 Debian 6.1.55-1 2023-12-03T11:35:03.335964+08:00 client kernel: [3792101.257081] Hardware name: System manufacturer System Product Name/PRIME B450M-A, BIOS 0219 06/08/2018 2023-12-03T11:35:03.335965+08:00 client kernel: [3792101.257082] Call Trace: 2023-12-03T11:35:03.335966+08:00 client kernel: [3792101.257085] 2023-12-03T11:35:03.335967+08:00 client kernel: [3792101.257088] dump_stack_lvl+0x44/0x5c 2023-12-03T11:35:03.335968+08:00 client kernel: [3792101.257094] dump_header+0x4a/0x211 2023-12-03T11:35:03.335978+08:00 client kernel: [3792101.257097] oom_kill_process.cold+0xb/0x10 2023-12-03T11:35:03.335979+08:00 client kernel: [3792101.257100] out_of_memory+0x1fd/0x4c0 2023-12-03T11:35:03.335980+08:00 client kernel: [3792101.257104] __alloc_pages_slowpath.constprop.0+0xc73/0xdc0 2023-12-03T11:35:03.335981+08:00 client kernel: [3792101.257108] __alloc_pages+0x305/0x330 2023-12-03T11:35:03.335982+08:00 client kernel: [3792101.257111] __folio_alloc+0x17/0x50 2023-12-03T11:35:03.335983+08:00 client kernel: [3792101.257113] ? policy_node+0x51/0x70 2023-12-03T11:35:03.335984+08:00 client kernel: [3792101.257116] vma_alloc_folio+0x9c/0x370 2023-12-03T11:35:03.335984+08:00 client kernel: [3792101.257119] __handle_mm_fault+0x92f/0xfa0 2023-12-03T11:35:03.335985+08:00 client kernel: [3792101.257123] handle_mm_fault+0xdb/0x2d0 2023-12-03T11:35:03.335986+08:00 client kernel: [3792101.257126] do_user_addr_fault+0x19c/0x570 2023-12-03T11:35:03.335986+08:00 client kernel: [3792101.257129] exc_page_fault+0x70/0x170 2023-12-03T11:35:03.335987+08:00 client kernel: [3792101.257132] asm_exc_page_fault+0x22/0x30 2023-12-03T11:35:03.335987+08:00 client kernel: [3792101.257136] RIP: 0033:0x7fcb86b0dd3a 2023-12-03T11:35:03.335988+08:00 client kernel: [3792101.257139] Code: 48 89 fb 48 83 ec 18 e8 b4 de ff ff 48 85 c0 74 42 48 89 c5 48 8b 43 48 48 3b 43 50 0f 84 5e 01 00 00 48 8d 50 08 48 89 53 48 <48> 89 28 4c 8b bb 88 00 00 00 4d 85 ff 74 16 41 80 7f 19 00 4d 8b 2023-12-03T11:35:03.335989+08:00 client kernel: [3792101.257140] RSP: 002b:7ffc85877cd0 EFLAGS: 00010283 2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257142] RAX: 7fcb0a3b7000 RBX: 7fcb45f33000 RCX: 05937a1b 2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257144] RDX: 7fcb0a3b7008 RSI: 7fcb85941410 RDI: 2023-12-03T11:35:03.335991+08:00 client kernel: [3792101.257145] RBP: 7fcb3ebaea08 R08: 7fcb3ebaea08 R09: 008fc63b 2023-12-03T11:35:03.335992+08:00 client kernel: [3792101.257146] R10: R11: 0008 R12: 0558afa25450 2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257147] R13: 7ffc85877d20 R14: R15: 148e1958de08 2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257150] 2023-12-03T11:35:03.335994+08:00 client kernel: [3792101.257151] Mem-Info: 2023-12-03T11:35:03.335994+08:00 client kernel: [3792101.257152] active_anon:202973 inactive_anon:7445439 isolated_anon:0 2023-12-03T11:35:03.335998+08:00 client kernel: [3792101.257152] active_file:816 inactive_file:3360 isolated_file:0 2023-12-03T11:35:03.335999+08:00 client kernel: [3792101.257152] unevictable:2092 dirty:0 writeback:0 2023-12-03T11:35:03.336000+08:00 client kernel: [3792101.257152] slab_reclaimable:180435 slab_unreclaimable:80961 2023-12-03T11:35:03.336001+08:00 client kernel: [3792101.257152] mapped:215565 shmem:310212 pagetables:40361 2023-12-03T11:35:03.336001+08:00 client kernel: [3792101.257152] sec_pagetables:0 bounce:0 2023-12-03T11:35:03.336002+08:00 client kernel: [3792101.257152] kernel_misc_reclaimable:0 2023-12-03T11:35:03.336004+08:00 client kernel: [3792101.257152] free:81539 free_pcp:87 free_cma:0 2023-12-03T11:35:03.336004+08:00 client kernel: [3792101.257156] Node 0 active_anon:811892kB inactive_anon:29781756kB active_file:3264kB inactive_file:13440kB unevictable:8368kB isolated(anon):0kB isolated(file):0kB mapped:862260kB dirty:0kB writeback:0kB shmem:1240848kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 17088512kB writeback_tmp:0kB kernel_stack:39
