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

Isolated Web Co Session crash Firefox-ESR

Started by	jeremy ardley <jeremy.ardley@gmail.com>
First post	2023-12-03 06:00 +0100
Last post	2023-12-03 14:00 +0100
Articles	20 on this page of 26 — 12 participants

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

  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 1 of 2 [1] 2 Next page →

#264134 — Isolated Web Co Session crash Firefox-ESR

From	jeremy ardley <jeremy.ardley@gmail.com>
Date	2023-12-03 06:00 +0100
Subject	Isolated Web Co Session crash Firefox-ESR
Message-ID	<HGMKd-aInC-1@gated-at.bofh.it>

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] <TASK>
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:00007ffc85877cd0 EFLAGS: 00010283
2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257142] RAX: 
00007fcb0a3b7000 RBX: 00007fcb45f33000 RCX: 0000000005937a1b
2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257144] RDX: 
00007fcb0a3b7008 RSI: 00007fcb85941410 RDI: 0000000000000000
2023-12-03T11:35:03.335991+08:00 client kernel: [3792101.257145] RBP: 
00007fcb3ebaea08 R08: 00007fcb3ebaea08 R09: 00000000008fc63b
2023-12-03T11:35:03.335992+08:00 client kernel: [3792101.257146] R10: 
0000000000000000 R11: 0000000000000008 R12: 00000558afa25450
2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257147] R13: 
00007ffc85877d20 R14: 0000000000000000 R15: 0000148e1958de08
2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257150] </TASK>
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

[toc] | [next] | [standalone]

#264135

From	Tom Furie <tom@furie.org.uk>
Date	2023-12-03 06:40 +0100
Message-ID	<HGNmW-aIV8-1@gated-at.bofh.it>
In reply to	#264134

jeremy ardley <jeremy.ardley@gmail.com> 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.

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

#264136

From	Phil Wyett <philip.wyett@kathenas.org>
Date	2023-12-03 07:10 +0100
Message-ID	<HGNPX-aJkB-11@gated-at.bofh.it>
In reply to	#264134

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

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] <TASK>
> 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:00007ffc85877cd0 EFLAGS: 00010283
> 2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257142] RAX: 
> 00007fcb0a3b7000 RBX: 00007fcb45f33000 RCX: 0000000005937a1b
> 2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257144] RDX: 
> 00007fcb0a3b7008 RSI: 00007fcb85941410 RDI: 0000000000000000
> 2023-12-03T11:35:03.335991+08:00 client kernel: [3792101.257145] RBP: 
> 00007fcb3ebaea08 R08: 00007fcb3ebaea08 R09: 00000000008fc63b
> 2023-12-03T11:35:03.335992+08:00 client kernel: [3792101.257146] R10: 
> 0000000000000000 R11: 0000000000000008 R12: 00000558afa25450
> 2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257147] R13: 
> 00007ffc85877d20 R14: 0000000000000000 R15: 0000148e1958de08
> 2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257150] </TASK>
> 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
> 

Hi,

As Tom stated, oom-killer is killing processes and it is not the brightest of things presently.

To begin to get a handle on this, it is time to ask what may seem like silly questions and consider
them, for which I apologise for in advance.

Your system RAM total is?

You have swap and it is enabled?

What Desktop Environment (DE) are you using - GNOME, KDE etc.?

How many apps would you normally be running on the system at once?

How many extensions have you installed/running in firefox?

How many tabs would you normally have open?

What type of content is generally being viewed/used in firefox?

When the system starts to become sluggish, have you looked at the firefox 'Task Manager' under tools
to see if anything stands out?

Others may wish more info, and this list is not exclusive.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org

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

#264138

From	jeremy ardley <jeremy.ardley@gmail.com>
Date	2023-12-03 07:40 +0100
Message-ID	<HGOiZ-aJtY-1@gated-at.bofh.it>
In reply to	#264136

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

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

#264139

From	Phil Wyett <philip.wyett@kathenas.org>
Date	2023-12-03 07:50 +0100
Message-ID	<HGOsG-aJxe-1@gated-at.bofh.it>
In reply to	#264138

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

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

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

#264140

From	jeremy ardley <jeremy.ardley@gmail.com>
Date	2023-12-03 08:10 +0100
Message-ID	<HGOM1-aJSw-3@gated-at.bofh.it>
In reply to	#264139

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 2555596 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 
Privileged Cont
3431066 jeremy    20   0 1134.0g 135080  95680 S   0.0   0.4 0:02.03 chrome
3423472 jeremy    20   0 1132.0g 134920  99712 S   0.0   0.4 0:03.81 chrome
3423418 jeremy    20   0 1132.0g 134056 100544 S   0.0   0.4 0:01.79 chrome
3428594 jeremy    20   0 1132.0g 133528  93660 S   0.3   0.4 0:08.06 
chromium
3423508 jeremy    20   0 1132.0g 132880  98768 S   0.0   0.4 0:02.97 chrome
3428508 jeremy    20   0   32.3g 131228 117312 S   0.0   0.4 0:00.04 
chromium
3428507 jeremy    20   0   32.3g 130952 118936 S   0.0   0.4 0:00.03 
chromium
3428611 jeremy    20   0 1132.0g 129212  93480 S   0.3   0.4 0:08.91 
chromium
3423254 jeremy    20   0   32.4g 129136 101388 S   0.0   0.4 0:28.94 chrome
3431762 jeremy    20   0 1134.0g 128600  95628 S   0.0   0.4 0:00.77 
chromium
3423409 jeremy    20   0 1132.0g 125972  94700 S   0.0   0.4 0:00.98 chrome

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

#264141

From	Tom Furie <tom@furie.org.uk>
Date	2023-12-03 08:30 +0100
Message-ID	<HGP5n-aJYl-1@gated-at.bofh.it>
In reply to	#264140

jeremy ardley <jeremy.ardley@gmail.com> 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.

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

#264143

From	jeremy ardley <jeremy.ardley@gmail.com>
Date	2023-12-03 09:10 +0100
Message-ID	<HGPI5-aKry-5@gated-at.bofh.it>
In reply to	#264140

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.

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

#264145

From	Phil Wyett <philip.wyett@kathenas.org>
Date	2023-12-03 10:40 +0100
Message-ID	<HGR7b-aL96-3@gated-at.bofh.it>
In reply to	#264143

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

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

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

#264177

From	Tom Dial <tddial@comcast.net>
Date	2023-12-04 02:50 +0100
Message-ID	<HH6fT-aUp5-1@gated-at.bofh.it>
In reply to	#264143

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.

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

#264148

From	Jeffrey Walton <noloader@gmail.com>
Date	2023-12-03 12:50 +0100
Message-ID	<HGT8Z-aMk7-3@gated-at.bofh.it>
In reply to	#264138

On Sun, Dec 3, 2023 at 6:21 AM jeremy ardley <jeremy.ardley@gmail.com> 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

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

#264169

From	Michael Kjörling <2695bd53d63c@ewoof.net>
Date	2023-12-03 23:10 +0100
Message-ID	<HH2OZ-aSpw-1@gated-at.bofh.it>
In reply to	#264138

On 3 Dec 2023 14:33 +0800, from jeremy.ardley@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?”

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

#264170

From	jeremy ardley <jeremy.ardley@gmail.com>
Date	2023-12-03 23:20 +0100
Message-ID	<HH2YF-aSsH-3@gated-at.bofh.it>
In reply to	#264169

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
                total        used        free      shared  buff/cache   available
Mem:           32023        9654       14053         336        9261       22369
Swap:            976           8         968

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

#264178

From	Max Nikulin <manikulin@gmail.com>
Date	2023-12-04 03:30 +0100
Message-ID	<HH6SB-aURe-1@gated-at.bofh.it>
In reply to	#264138

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.

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

#264179

From	jeremy ardley <jeremy.ardley@gmail.com>
Date	2023-12-04 03:50 +0100
Message-ID	<HH7bX-aUXu-3@gated-at.bofh.it>
In reply to	#264178


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.

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

#264180

From	Max Nikulin <manikulin@gmail.com>
Date	2023-12-04 04:00 +0100
Message-ID	<HH7lD-aV0w-1@gated-at.bofh.it>
In reply to	#264179

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.

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

#264253

From	jeremy ardley <jeremy.ardley@gmail.com>
Date	2023-12-04 22:40 +0100
Message-ID	<HHoPv-bbeb-21@gated-at.bofh.it>
In reply to	#264180

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.

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

#264307

From	jeremy ardley <jeremy.ardley@gmail.com>
Date	2023-12-05 19:50 +0100
Message-ID	<HHIEx-bsNW-1@gated-at.bofh.it>
In reply to	#264178

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

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

#264315

From	<tomas@tuxteam.de>
Date	2023-12-06 06:10 +0100
Message-ID	<HHSky-bBbq-1@gated-at.bofh.it>
In reply to	#264307

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

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

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

#264320

From	Karl Vogel <vogelke@pobox.com>
Date	2023-12-06 10:20 +0100
Message-ID	<HHWet-bEpH-7@gated-at.bofh.it>
In reply to	#264315

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.

-- 
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
#<swap2ram: get swap manually back into RAM.
#           Send results to stdout unless running from cron.

export PATH=/bin:/usr/bin:/sbin
export LC_ALL=C
tag=${0##*/}

# I set the environment variable "CRON" to yes in all crontabs.
case "$CRON" in
    yes)
        logmsg ()  { logger -t "$tag" "$@" ; }
        logfile () { fn="$1"; logger -t $tag -f "$fn" ; }
        ;;

    *)
        logmsg ()  { echo "$(date '+%F %T') $tag: $@"; }
        logfile () { fn="$1"; cat "$fn" ; }
        ;;
esac

die () { logmsg "FATAL: $@"; exit 1; }

# Do we need root to run this?
needroot () {
    case "$1" in
        "") action='do' ;;
        *)  action="$1" ;;
    esac

    id | grep 'uid=0(root)' > /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.XXXXXX")
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

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

Page 1 of 2 [1] 2 Next page →

csiph-web

Isolated Web Co Session crash Firefox-ESR

Contents

#264134 — Isolated Web Co Session crash Firefox-ESR

#264135

#264136

#264138

#264139

#264140

#264141

#264143

#264145

#264177

#264148

#264169

#264170

#264178

#264179

#264180

#264253

#264307

#264315

#264320