Mailinglist Archive: opensuse-support (176 mails)

< Previous Next >
Re: [opensuse-support] Unresponsive desktop
  • From: Peter Suetterlin <pit@xxxxxxxxxxx>
  • Date: Sun, 3 Feb 2019 17:35:56 +0100
  • Message-id: <20190203163556.GG420@lux.pit.lunda16>
Carlos E. R. wrote:

I had no chance to kill firefox, system froze while I tried to issue the

The laptop has 4 gigs, the desktop has 8, so it takes longer to crash.

I might have to start firefox with ulimit, but I don't know what limits
to give it.

This sounds similar to my hangs when my image processing started using more
RAM than physically available, and it pushed anything from the GUI into swap.
So any UI interaction would need swap-in, but that one had been busy due to
the processing. In my case it was 'dead' for almost an hour - and then came
back as if nothing happened....

My solution had been to limit the process using cgroups to not use more than
MEM-2GB physical RAM. In other words, as soon as it wants more than that
amount, it starts using swap. That leaves enough memory for the GUI to remain

For my machine here (16GB) the setup script looks like this:

lux:~ # cat bin/mk14Ggroup
mkdir /sys/fs/cgroup/memory/14G
echo 15032385536 > /sys/fs/cgroup/memory/14G/memory.limit_in_bytes
chown root.users /sys/fs/cgroup/memory/14G/cgroup.procs
chmod 775 /sys/fs/cgroup/memory/14G/cgroup.procs

Any user can then
echo $PID > /sys/fs/cgroup/memory/14G/cgroup.procs
and the process $PID will be limited that way.

I've even considered doing this on the main level, i.e.,
echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes

Then no process at all can use up all memory. I have not checked though if
that works as intended. You might give it a try (of course with some smaller
limit, something like 6.5-7GB for the 8GB machine)
To unsubscribe, e-mail: opensuse-support+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-support+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation