I have two Leap 15.1 KDE installs (one Dell Precision M6400, one Libretrend box), since last summer/fall both show a strange behaviour. They normally stream some VLC (via http, from raspberry pi machines) OR do a little VNC to other opensuse machines or raspberry pis. Sometimes a little Firefox/palemoon.
After some days, the RAM is apparently full (or at least the orange bar in htop fills up RAM available). And then the machine crashes.
Here a htop for one of the machines shortly before a crash
I am not sure where you have seen it. You need to find out what is causing memory shortage. If you add swap and something will continue to allocate (and actually use) more and more memory you simply end up with Out-Of-Memory again (but before you will probably observe significant delays due to swapping).
But when I bought another 4GB RAM for the Dell it only took a little longer until the system froze
You should know that although I haven’t heard any recent reports,
Firefox has had a long history of memory leaks causing things like what you are describing (memory completely allocated).
Most of the time the problem wasn’t the Firefox app itself but poorly written plugins, and because of the permissive “open” policies that allowed their wide installation and use.
In some ways you can consider it a potential issue that happens when you also want an extremely large variety of plugins available.
Mozilla has gradually tightened up policies over time, but things happen.
You may want to shutdown your Firefox browser often.
You may want to be careful about installed plugins, particularly those that support deprecated technologies like palemoon. When a base technology is no longer supported, then the various related technologies may also receive less attention. The whole ecology then may start to fail.
Another consideration is if your machine is very active.
all OS will prefer to use all (or nearly all) physical resources before de-allocating so that the resources can be used elsewhere. Data in RAM is only marked for de-allocation and returned to a pool for re-use availability only when there is resource pressure.
Typically this works fine for most workloads… The idea is that as long as the data is already in RAM, if the data is re-accessed then it’s available otherwise computation to produce that result would have to happen again.
Of course the above assumes a <normal> workload.
If the workload suddenly changes, then of course all that data in RAM is worthless.
Although the OS will “learn” your new workload has nothing to do with what was being done before, that can take time.
In this instance, you can manually flush your memory buffers, I provide that command at the end of my Wiki article on the Free tool (and if you’re using Free it might be worth a look to be sure you’re using the tool properly)
If you really feel that memory exhaustion is crashing your machine, the command I give you should address that as a short term fix. Of course, your memory may fill up again and then it’ll be your decision whether to run the command again or if you think the OS will resolve the issue on its own.
The other thing to look at is if you notice your crashes might be related to a particular app…
You mention VLC which has given me problems intermittently in the past…
From time to time I’ve had to tinker with how much data is buffered, it’s like a Goldilocks… Can’t be too large or too small, there is an amount that’s just right.
Less frequently, I’ve switched codecs from gstreamer to ffmpeg and vice versa.
VLC has been a temperamental app at times but not continuously for me.
No, it’s not “very active”. Both sitting there and doing the VNC or VLC jobs I described. Not more.
Please, something that matches the situation! If you need more details, OK, but I think I provided the relevant info…
I’m not willing to run any commands every other day, the machines should do things on their own (otherwise I could set up a cron job to reboot every night, but that would be a crude hack. I want to know what is going on here).
Sorry for my comment #9, used to “top” I didn’t realize immediately that the linked image showed “htop” with its odd (to me) way of reporting memory.
Nevertheless, the screenshot clearly shows that RAM is exhausted and the system is about to “crash”, but it doesn’t show why.
Finger pointing at Firefox doesn’t help (some 1% of reserved memory), Xvnc is much larger (some 1.4GB reserved + 1.3GB shared) but still manageable apparently.
The systems currently (in the last few posts) are far from memory starving, so the simple fact that RAM usage is increasing with uptime doesn’t tell much.
Maybe running “top” sorted by “%MEM” (try hitting > or <) can quickly show what processes use most RAM and if any of those dramatically increase their use with uptime.
Of course more experienced sysadmins may suggest other tools…
To a point, simply setting up a swap improves memory allocation, even if it is never actually used.
But if there is a memory leak somewhere it will show up again; possibly having a swap might allow you to catch the culprit and kill it before the system crashes…