Clear encrypted SWAP memory?

Crivens said:
Is it cleaned up when you restart the browser?
Click to expand...
Ok - I tried this. Think we are finally making progress about where the swap is going.

So first of all I shut down the large Chromium instance (killed the main process via htop, which made the browser instance disappear, relevant below). What happened to swap usage? Surprisingly nothing!

But then I started looking at htop, I noticed there were other processes still running in htop starting with "chrome -something-something". I tried by luck by killing them (there were many, I reckon more than 50 at least) and viola - it reduced active swap usage from 7.75GB (almost full) to 700 MB when I got rid of every single chrome process!

SWAP was redeemed - I think these Chromium processes are the culprit.

So quick question:
1) Why are these "extra" processes (since they didn't close with the Chromium instance) hanging around after closing of the browser instance?
2) Is a possible solution to my swap full usage issue - to keep killing these extra processes from htop? Or is there a better alternative? (killing them one by one can be a pain)
grahamperrin said:
It may take some time for window content to appear entirely as it should. The waiting period, after resizing a window, may be longer if the system is noticeably busy.

That said, I don't recall ever seeing an amount used (i.e.more than zero) with zero processes listed.
Click to expand...
I think I tried to see it even when the system load was manageable - still yielded nothing.
 
Chromium, Settings, "System" page. At top is "Continue running background apps when Chromium is closed", make sure that option is off.
Not exactly sure if how applicable to FreeBSD that option is, but I've always turned it on all my systems where I run Chrome/Chromium.

www.howtogeek.com

How to Make Chrome Use Less RAM

Chrome eating up RAM? Of course it is. Here's what you can do.
www.howtogeek.com www.howtogeek.com
This one from almost 13 years ago:
superuser.com

Why does Google Chrome leave running processes behind even after closing the browser?

Even when I close Chrome, I can see running processes of that instance in the Task Manager. If I had initiated three instances of Chrome, I could see three Chrome.exe in the Task Manager. Why aren'...
superuser.com superuser.com
 
mer said:
Chromium, Settings, "System" page. At top is "Continue running background apps when Chromium is closed", make sure that option is off.
Click to expand...
Will try to do this BUT

In an ideal situation : I don't want to be closing Chromium for as long as possible (a nasty side effect of this is that I need to login again on every site, specially when I kill the Chromium process)

Wouldn't it make more sense to kill these "extra" chromium processes themselves rather than the instance of Chromium? (they were present in htop even before trying to kill the main chromium process itself - not sure what gives rise to these extra processes)
 
Tracker said:
Wouldn't it make more sense to kill these "extra" chromium processes themselves rather than the instance of Chromium? (they were present in htop even before trying to kill the main chromium process itself - not sure what gives rise to these extra processes)
Click to expand...
Yes it may make more sense; I think one of the links I give has something in Chrome itself that will show the processes/threads and you can kill them.

One of the links addresses the "extra processes" part: extensions, addons could give rise to them, also seems tied to number of open tabs. I think the first article had a link to something called "memory saver" supposedly came in around v110, "on" by default that reduces memory use of background pages/tabs you haven't interacted with in a while. I checked on a up to date Windows Chrome and it was off (I never turned it on or off) and Chromium on FreeBSD it was also off (again never turned it on or off).

Based on your usage pattern (lots of tabs open) check Memory Saver (first option under Settings, Performance). There may be side effects of enabling it.
 
Tracker said:
Ok - I tried this. Think we are finally making progress about where the swap is going.

So first of all I shut down the large Chromium instance (killed the main process via htop, which made the browser instance disappear, relevant below). What happened to swap usage? Surprisingly nothing!

But then I started looking at htop, I noticed there were other processes still running in htop starting with "chrome -something-something". I tried by luck by killing them (there were many, I reckon more than 50 at least) and viola - it reduced active swap usage from 7.75GB (almost full) to 700 MB when I got rid of every single chrome process!

SWAP was redeemed - I think these Chromium processes are the culprit.

So quick question:
1) Why are these "extra" processes (since they didn't close with the Chromium instance) hanging around after closing of the browser instance?
2) Is a possible solution to my swap full usage issue - to keep killing these extra processes from htop? Or is there a better alternative? (killing them one by one can be a pain)

I think I tried to see it even when the system load was manageable - still yielded nothing.
Click to expand...

You should kill Chrome processes from Chrome's own task manager (in "more tools"). It also allows you to sort by size. That way you can tell tabs from the main process and you don't take down the entire browser.

As mentioned, by default Chrome indeed continues to work in the background. You can turn that off, but it probably doesn't make a RAM difference.
 
Looks like chrome spawns these and keeps them running "just in case", and then these idle processes are swapped out completely. Maybe you need to impose some rlimits on chrome? Is that possible?
 
Crivens said:
Looks like chrome spawns these and keeps them running "just in case", and then these idle processes are swapped out completely. Maybe you need to impose some rlimits on chrome? Is that possible?
Click to expand...
How could I do that?

So now I'm facing the same issue - despite having 64G of memory the swap is being used by Chrome/others and it makes the system *extremely* slow once swap fills up!

This is becoming more problematic when I don't reboot for ~20 days or so, smithi mentioned he doesn't for months iirc - how do you manage?

Someone also suggested to not turn off swap - what are the downsides of not having swap? Seems like the best thing to do since this keeps recurring.
 
What about doing a periodic kill -9 on chrome? Faster that rebooting, and the swap should be reclaimed. At restart the tabs should be reopened. Now you can check how much memory this working set really needs, and how much is memory lost by chrome. I would think it pretty impossible to not loose memory in that beast, that problem might also be NP.
 
Cath O'Deray said:
Occasional restarts of the OS. Less frequently: reboot -r

These restarts are:

- for routine updates
- not to avoid use of swap.
Click to expand...
My purpose **is** to avoid usage of swap - since that seems to be the main issue somehow (once it gets full, its VERY SLOW and random tabs crashing). Routine updates yea - that's good to have but a) they don't _necessarily_ require a restart - so to do it without requirement seems superfluous b) Sometimes updating causes the Chrome browser to update and then it seems to require a restart - is that usually the case upon updating a package? Or maybe it's another weird experience I've had due to this issue.
Crivens said:
What about doing a periodic kill -9 on chrome? Faster that rebooting, and the swap should be reclaimed. At restart the tabs should be reopened. Now you can check how much memory this working set really needs, and how much is memory lost by chrome. I would think it pretty impossible to not loose memory in that beast, that problem might also be NP
Click to expand...
Hmm yea I usually attempt to pkill -15 (from htop with k and default option of 15) when it gets very slow. I don't opt for the kill for chrome itself because I have the habit of working with quite a few incognito tabs as well - so I prefer to not use kill. Ideally I just want to avoid swap now I think - I still don't understand what I stand to lose if I disable swap? (someone earlier recommended not to disable it - but I don't see another way out , for my situation)
Cath O'Deray said:
With respect: those outputs from systat -swap make no sense, to me.
Click to expand...
Here you go again - tried it for you just now - no pid/username/command/etc
Code: 
                   /0   /1   /2   /3   /4   /5   /6   /7   /8   /9   /10
     Load Average   ||||||||||||||||||||||||||||| 

Device/Path       Size  Used |0%  /10  /20  /30  /40  / 60\  70\  80\  90\ 100|
ada0p4.eli       7932M 7932M XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Pid    Username   Command     Swap/Total Per-Process    Per-System
 
Why should I not disable swap at this point? I don't see another way out ....

Disabling it won't lead to this swap getting full (due to memory leakage presumably) issue to begin with .... me thinks

Besides this swap getting full is also hurting the life of my hard disk I guess
 
Tracker said:
… swap getting full is also hurting the life of my hard disk I guess
Click to expand...

I doubt it.

Tracker said:
Here you go again - tried it for you just now - no pid/username/command/etc
Click to expand...

Try a run when use of swap is minimal but not zero.

Be very patient, and refrain from resizing the window. Leave the window in front, hands off the keyboard, watch and wait.

With relatively low use: the waiting period for a list of processes should be relatively short. With relatively high use: a relatively long wait.

Cath O'Deray said:
gstat(8)
  • gstat -op
  • gstat -aop
systat(1)
  • systat -swap (considerable use of CPU, so I don't run it for longer than is necessary)
Click to expand...
 
The big question here is whether the application leaks and is growing without bounds. If yes it needs to be restarted every now and then. (or fixed)

That takes care of overuse of swap space.

Removing all swap space without changing anything else will obviously lead to more out-of-memory conditions.
 
Commented out swap file from /etc/fstab ? - since nobody would tell me what the downsides were in my situation -let's see how this goes ?

cracauer@ said:
The big question here is whether the application leaks and is growing without bounds.
Click to expand...
Not sure it needs to grow out of bounds - for me the issue is it's filling up swap space - that's enough to cause the primary issue for me. Always shows enough unutilized memory even when that happens.
cracauer@ said:
Removing all swap space without changing anything else will obviously lead to more out-of-memory conditions.
Click to expand...
Isn't 64G enough to take care of that?
 
Tracker said:
Commented out swap file from /etc/fstab ? - since nobody would tell me what the downsides were in my situation -let's see how this goes ?


Not sure it needs to grow out of bounds - for me the issue is it's filling up swap space - that's enough to cause the primary issue for me. Always shows enough unutilized memory even when that happens.

Isn't 64G enough to take care of that?
Click to expand...

If it is growing out of 64 GB with few tabs it is leaking.
 
cracauer@ said:
If it is growing out of 64 GB with few tabs it is leaking.
Click to expand...
No - that's not the case.

To be specific
1) I have more than a *few* tabs
2) The leak was happening with swap getting full. Memory (64G in all) was never reported to be full.
 
To address 1)
That sounds a little messy. But it might to work. On the other hand, chrome is known to be a memory hog, so having *a lot* of tabs open is tickeling the dragons tail IMHO.

As for 2), how the memory system works has been explained on this forum time and time again. The leak is happening way before that memory hits the swap space. Now you will reach the point of failure sooner. But the failure is unavailable when chrome is leaking.
 
Crivens said:
To address 1)
That sounds a little messy. But it might to work. On the other hand, chrome is known to be a memory hog, so having *a lot* of tabs open is tickeling the dragons tail IMHO.
Click to expand...
It's messy but I think Chrome takes care of not allocating memory for most of the background tabs (I'm talking about a thousand plus tabs) - so in that respect it's fine as an app. Just the swap leakage was messing with my system. Now I'm on a no-swap system. Will see how this goes.
Crivens said:
As for 2), how the memory system works has been explained on this forum time and time again. The leak is happening way before that memory hits the swap space. Now you will reach the point of failure sooner. But the failure is unavailable when chrome is leaking.
Click to expand...
If memory leakage happens before it hits the swap - then I guess i'll be back to zero ?
 
Tracker said:
If memory leakage happens before it hits the swap
Click to expand...
Memory leakage happens in the app, the OS has no way to know if the allocated memory is still referenced or not. For that, you need languages with an inbuild garbage collector, and C/C++ is not among those. And even then, the garbage collector is not in the OS but the runtime system. The leaking will most likely happen somewhere in the javascript parts, and it will accumulate. Maybe you can set some rlimits for chrome, see what happens when it does not get to allocate all it can get. Maybe it has a garbage collector, but that is not triggered as long as there still is memory to get.
 
Crivens said:
Maybe you can set some rlimits for chrome, see what happens when it does not get to allocate all it can get.
Click to expand...
How can I set limits for chrome?
Crivens said:
Maybe it has a garbage collector, but that is not triggered as long as there still is memory to get
Click to expand...
If it matters - My 64G memory was never full, somehow the memory leaked into swap though - thus causing the slowdown. ALways have ~30G memory unused, even when swap got full and made the system slow.
 
You must log in or register to reply here.
Back
Top