[SOLVED]emerge freezes my system to unusable

Message

cz0 · Post by **cz0** » Thu Apr 23, 2020 12:02 pm

Hi folks!
In recent update a new spidermonkey-60.5.2_p0-r4 rolled in, so I decided to go -uDNpv right in. That lead to a total system freeze and failure. After a couple of forerunners like sound breaks and mouse pointer jumps I got my system totally locked with no possibility to switch to console, not even close Firefox window and disk led constantly lit. I had to powercycle the machine loosing all my ssh sessions to return machine to working condition again.

Even my Lenovo X230 laptop is kind of oldish, it still far from been weak: i5-3230M @ 2.6 GHz + 16 Gb of RAM + modern Samsung SSD 860 EVO 500GB. I had no active VMs and just a dozen of plane tabs in Firefox. I've faced such freezes before on my work laptop, so I have vm.oom_kill_allocating_task enabled in sysctl.conf as well. Besides, I have MAKEOPTS="-j5" on my make.conf, but this doesn't seem to be a problem. The amount of free space and inodes on disk are more then sufficient.

Can anybody suggest something to circumvent such dead freezes? OOM killer seem not to do it's job at all. The good solution is to kill compilation process in case if severe OOM condition.

UlFie · Post by **UlFie** » Thu Apr 23, 2020 7:30 pm

Maybe you should have some swap space available? And keep an eye on memory usage with a tool like ksysguard (I guess pretty much any desktop environment has something similar), at least around the time you start something that might be resource intensive? My experience is that browsers tend to clutter memory, not compilation jobs. Yet there are settings that may have influence on memory usage (like CFLAGS="-pipe").

cz0 · Post by **cz0** » Thu Apr 23, 2020 7:45 pm

UlFie wrote:Maybe you should have some swap space available? And keep an eye on memory usage with a tool like ksysguard (I guess pretty much any desktop environment has something similar), at least around the time you start something that might be resource intensive? My experience is that browsers tend to clutter memory, not compilation jobs. Yet there are settings that may have influence on memory usage (like CFLAGS="-pipe").

Having swap with 16 Gigs of RAM and SSD does not sound like a good idea. I used to have swap of 4 Gb AFAIR when I had 8 Gigs of RAM and HDD and I experienced same dead freezes. Watching after system is not a solution ether: basically you have no time to react - when you see the system start to suffer it is already to late to do anything about it. And you'll never know how much RAM you need for the next source and when it will be compiled in the long update list. My CFLAGS="-march=native -O2 -pipe".

Post by **NeddySeagoon** » Thu Apr 23, 2020 8:32 pm

cz0,

Swap is always a good idea. Its only used for dynamically allocated RAM.
Not having swap does not prevent the kernel swapping, it only robs it of its option to save to disk, dynamically allocated RAM.

The kernel will flush anything, code, or data, that has a permanent home on disk if it needs more RAM.
It can always be reloaded for the cost of a page fault.
'Dirty' pages need to be written before they are dropped.

The OOM is a last ditch thing for use by the kernel to allocate RAM for its own use.
With all that swapping going on that you are not aware of, things get very very slow, which is what you report.

Reducing MAKEOPTS will help take the pressure off RAM.
Where is your build space, is that in RAM too?
tmpfs can be moved to swap to free RAM.

cz0 · Post by **cz0** » Thu Apr 23, 2020 9:06 pm

NeddySeagoon wrote: Reducing MAKEOPTS will help take the pressure off RAM.
Where is your build space, is that in RAM too?
tmpfs can be moved to swap to free RAM.

A was thinking about lowing -j from 5 to lets say 3.. maybe.
The build space is on SSD. So I have 16 Gig of RAM just for KDE + Firefox with a dozen of lightweight tabs and emerge doing it's business. Actually, I think this is uptime related. I had emerge -e complete fine for many times before, but suddenly I get this dead lock.

cz0 · Post by **cz0** » Sat Apr 25, 2020 9:25 am

O lowed make jobs from Nthreads+1 to Nthreads-1 and that actually reduced compilation time. A also added load-average with the Nthreads to prevent make from overloading the system.
But this is just some minor tweaks. The guilty one is... Firefox. Being running for many days it simply leaked out and ate all the RAM. I found that this s*cker can literally take all the available memory. In my case 15 gigs out of 16, leaving no space for compiler to do it's job. I have never noticed this thing to be so greedy. I'm thinking of limiting it using some kind of plane cgroups/firejail (as I already use it not to fight cgroups directly)/ulimit maybe. Will make experiments to figure out what suits better.

Post by **NeddySeagoon** » Sat Apr 25, 2020 9:40 am

cz0,

Watch out for your thermal throttling warnings. That indicate overheating.
As its a laptop, there will be little you cat do about it. Small size, good performance, low power and thermal design always involve tradeoffs.
Most users will not push their systems hard for several hours at a time, so thermal design does not take that use case into account.

In other words its likely that your laptop is not designed to build Gentoo.

cz0 · Post by **cz0** » Sun Apr 26, 2020 8:34 am

NeddySeagoon wrote: In other words its likely that your laptop is not designed to build Gentoo.

Well, no. I've seen such warnings on cheapish Lenovo T640p, but never on my Lenovo X230. It is running Gentoo since 2013, AFAIR, and seen many full recompilations since that and I never seen any thermal issues. So, differently this is not the case for X230.