Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #264134 > unrolled thread

Isolated Web Co Session crash Firefox-ESR

Back to article view | Back to linux.debian.user

Contents

  Isolated Web Co Session crash Firefox-ESR jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-03 06:00 +0100
    Re: Isolated Web Co Session crash Firefox-ESR Tom Furie <tom@furie.org.uk> - 2023-12-03 06:40 +0100
    Re: Isolated Web Co Session crash Firefox-ESR Phil Wyett <philip.wyett@kathenas.org> - 2023-12-03 07:10 +0100
      Re: Isolated Web Co Session crash Firefox-ESR jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-03 07:40 +0100
        Re: Isolated Web Co Session crash Firefox-ESR Phil Wyett <philip.wyett@kathenas.org> - 2023-12-03 07:50 +0100
          Re: Isolated Web Co Session crash Firefox-ESR jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-03 08:10 +0100
            Re: Isolated Web Co Session crash Firefox-ESR Tom Furie <tom@furie.org.uk> - 2023-12-03 08:30 +0100
            Re: Isolated Web Co Session crash Firefox-ESR jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-03 09:10 +0100
              Re: Isolated Web Co Session crash Firefox-ESR Phil Wyett <philip.wyett@kathenas.org> - 2023-12-03 10:40 +0100
              Re: Isolated Web Co Session crash Firefox-ESR Tom Dial <tddial@comcast.net> - 2023-12-04 02:50 +0100
        Re: Isolated Web Co Session crash Firefox-ESR Jeffrey Walton <noloader@gmail.com> - 2023-12-03 12:50 +0100
        Re: Isolated Web Co Session crash Firefox-ESR Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-12-03 23:10 +0100
          Re: Isolated Web Co Session crash Firefox-ESR jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-03 23:20 +0100
        Re: Isolated Web Co Session crash Firefox-ESR Max Nikulin <manikulin@gmail.com> - 2023-12-04 03:30 +0100
          Re: Isolated Web Co Session crash Firefox-ESR jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-04 03:50 +0100
            Re: Isolated Web Co Session crash Firefox-ESR Max Nikulin <manikulin@gmail.com> - 2023-12-04 04:00 +0100
              Re: Isolated Web Co Session crash Firefox-ESR jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-04 22:40 +0100
          Re: Isolated Web Co Session crash Firefox-ESR jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-05 19:50 +0100
            Re: Isolated Web Co Session crash Firefox-ESR <tomas@tuxteam.de> - 2023-12-06 06:10 +0100
              Re: Isolated Web Co Session crash Firefox-ESR Karl Vogel <vogelke@pobox.com> - 2023-12-06 10:20 +0100
                Re: Isolated Web Co Session crash Firefox-ESR debian-user@howorth.org.uk - 2023-12-06 13:00 +0100
              Re: Isolated Web Co Session crash Firefox-ESR Max Nikulin <manikulin@gmail.com> - 2023-12-06 15:30 +0100
                Re: Isolated Web Co Session crash Firefox-ESR <tomas@tuxteam.de> - 2023-12-06 16:00 +0100
            Re: Isolated Web Co Session crash Firefox-ESR Max Nikulin <manikulin@gmail.com> - 2023-12-06 15:50 +0100
    Re: Isolated Web Co Session crash Firefox-ESR David Christensen <dpchrist@holgerdanske.com> - 2023-12-03 08:50 +0100
    Re: Isolated Web Co Session crash Firefox-ESR Reco <recoverym4n@enotuniq.net> - 2023-12-03 14:00 +0100

Page 2 of 2 — ← Prev page 1 [2]

#264321

Karl Vogel <vogelke@pobox.com> wrote:
> On Wed, Dec 06, 2023 at 06:04:36AM +0100, tomas@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

[toc] | [prev] | [next] | [standalone]

#264326

On 06/12/2023 12:04, tomas@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.

[toc] | [prev] | [next] | [standalone]

#264330

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 06, 2023 at 09:27:06PM +0700, Max Nikulin wrote:
> On 06/12/2023 12:04, tomas@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

[toc] | [prev] | [next] | [standalone]

#264327

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.

[toc] | [prev] | [next] | [standalone]

#264142

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<snip>


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

[toc] | [prev] | [next] | [standalone]

#264151

	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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web