1

Edit 1: The freezing just happened and I was able recover from it. Log(syslog) from the freezing until 'now': https://ufile.io/ivred

Edit 2: It seems a bug/problem with GDM3. I'll try Xubuntu.

Edit 3: Now I'm using Xubuntu. The problem still happens, but a lot less often. So.. it is indeed a memory issue.

I'm currently using Ubuntu 18.10 Live CD since my HD died. I did some customizations to my LiveCD mainly towards memory consumption, because I have only 4GB of RAM.

When my free memory goes below 100MB, my pendrive LED starts to blink like crazy and the system freezes letting me time to just get out of GUI interface (Ctrl+Alt+f1...f12) and reboot(Ctrl+Alt+Del) or, sometimes to close Google Chrome with sudo killall chrome.

So I created a very simple script to clean the system cache and close Google Chrome. Closing Chrome out of the blue like that is fine, since it asks you to recover the tabs when it wasn't closed properly.

The question: It works like a charm 95% of the time. I don't know if my script is too simple or there is another reason for this intermittent freezing since I can't check the log, because of the need of reboot. Is there a more efficient way to do that? Am I doing it wrong?

Obs.: I have another script to clean the cache that runs every 15 minutes. Since I created those scripts I am able to use my LiveCD every day with almost no freezing. Maybe 1 per day.. Before that I had to reboot every 30-40min, because I use the Chrome with several tabs.

My script:

#!/bin/bash 

while true ; do 
free=`free -m | grep Mem | awk '{print $4}'`
if [ "$free" -gt 0 ]
 then
    if [ $free -le 120 ]; #When my memory consuptiom goes below 120MB do the commands below. 
     then

if pgrep -x "chrome" > /dev/null
then
        sudo killall -9 chrome
        sudo su xubuntu
        /usr/bin/google-chrome-stable --password-store=basic --aggressive-cache-discard --aggressive-tab-discard
else
    echo "Stopped"
fi

    sudo sysctl -w vm.drop_caches=3
        sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches 



    fi
fi & sleep 1; done
slava
  • 173
  • 1
    Do you have swap partition on pendrive? Then disable it. swapoff -a. – Ipor Sircer Nov 24 '18 at 17:21
  • No swap partition on my pendrive. – Lucas Rizzini Nov 24 '18 at 17:39
  • 3
    Then teach chrome to use less ram. Look at parameters, for example: --mem-pressure-system-reserved-kb=XXX, --aggressive-cache-discard, --aggressive-tab-discard, etc... 4gb is fairly enough to run chrom[e|ium] nowadays. My chromium nevers eats more than 2.6gb in any conditions (even with 50+ opened tabs). – Ipor Sircer Nov 24 '18 at 18:23
  • use an real open source less RAM extensive browser, or maybe try to not open too much tab – Kiwy Nov 28 '18 at 10:44
  • I need to use Google Chrome and a lot of tabs. Otherwise, I would have already changed my browser. – Lucas Rizzini Nov 28 '18 at 12:29
  • " I created a very simple script to clean the system cache and close Google Chrome." I doubt that this is the way to go. Low memory has been a very common problem in the past, and many solutions have been developped. Except in vary rare cases I expect the standard (kernal/OS) supplied stuff to work better than anything homebrewed. – Hennes Nov 30 '18 at 11:55
  • A completely different point: Why do you erase the disk cache? It has nothing to do with memory and disk cache size is perfectly configurable in the browser. (I guess I am saying leave that to the browser rather then create a home brewed solution, similar to previous comment). – Hennes Nov 30 '18 at 11:57
  • I guess that one of the standard solutions to this kind of issue would be using cgroups. See, for example, https://unix.stackexchange.com/questions/419406/chrome-eats-all-ram-and-freezes-system – fra-san Nov 30 '18 at 12:03

2 Answers2

0

The solution that "fra-san" gave at the comments here fitted perfectly. Using "cgroup-tools" package I was able to limit Chrome memory usage successfully. I tested it opening dozens of tabs at the same time and I could see the memory limit in action. However, I had to leave my script running, since, as much as I mostly use Chrome, system cache consumes a lot of RAM too.

My steps:

1- Used this script from: Limit memory usage for a single Linux process

#!/bin/sh

# This script uses commands from the cgroup-tools package. The cgroup-tools commands access the cgroup filesystem directly which is against the (new-ish) kernel's requirement that cgroups are managed by a single entity (which usually will be systemd). Additionally there is a v2 cgroup api in development which will probably replace the existing api at some point. So expect this script to break in the future. The correct way forward would be to use systemd's apis to create the cgroups, but afaik systemd currently (feb 2018) only exposes dbus apis for which there are no command line tools yet, and I didn't feel like writing those.

# strict mode: error if commands fail or if unset variables are used
set -eu

if [ "$#" -lt 2 ]
then
    echo Usage: `basename $0` "<limit> <command>..."
    echo or: `basename $0` "<memlimit> -s <swaplimit> <command>..."
    exit 1
fi

cgname="limitmem_$$"

# parse command line args and find limits

limit="$1"
swaplimit="$limit"
shift

if [ "$1" = "-s" ]
then
    shift
    swaplimit="$1"
    shift
fi

if [ "$1" = -- ]
then
    shift
fi

if [ "$limit" = "$swaplimit" ]
then
    memsw=0
    echo "limiting memory to $limit (cgroup $cgname) for command $@" >&2
else
    memsw=1
    echo "limiting memory to $limit and total virtual memory to $swaplimit (cgroup $cgname) for command $@" >&2
fi

# create cgroup
sudo cgcreate -g "memory:$cgname"
sudo cgset -r memory.limit_in_bytes="$limit" "$cgname"
bytes_limit=`cgget -g "memory:$cgname" | grep memory.limit_in_bytes | cut -d\  -f2`

# try also limiting swap usage, but this fails if the system has no swap
if sudo cgset -r memory.memsw.limit_in_bytes="$swaplimit" "$cgname"
then
    bytes_swap_limit=`cgget -g "memory:$cgname" | grep memory.memsw.limit_in_bytes | cut -d\  -f2`
else
    echo "failed to limit swap"
    memsw=0
fi

2- Named it as "limitmem" and copied to /usr/bin/ so I could call it from terminal just with limitmem. Now I can open a process limiting the memory usage to, for example, 800MB using this syntax:limitmem 800M command

In my case: limitmem 1000M google-chrome --password-store=basic --aggressive-cache-discard --aggressive-tab-discard

  • This seems promising. Does this script automates the entire process of creating cgroups? or do I have to create the cgroup before using it? What is the package that I need to install in order to use it? – Winampah Feb 14 '22 at 02:10
0

You asked if you are doing it the most efficient way. I have been using a laptop in a very similar way. Things I notice from using a LiveUSB for 3 years:

  1. Try to not use apt-get install to install packages; use sudo dpkg -i instead.  This seems to keep the "shared" memory lower (the system files that are modified and thus occupy more memory in the RAMdisk).
  2. You don't need to kill the entire Chromium process tree; you can kill only the "left-over" closed tabs it leaves behind (usually called --type=renderer processes). You do this by running:
    ps aux | grep type=renderer
    kill -9 $(ps aux | grep type=renderer)
    

    You can assign a keyboard shortcut to run a script which contains the kill command. This way you don't have to reload the entire browser; you only click the notification popup to reload extensions. Memory overhead after that keeps very low for any reason.

  3. I used to use the clean cache/buffers command many times a day, but I noticed over time that I only need to pay attention to the "Available" memory instead of the "Free" memory. My system remains functional with only 100 MB Free. I have only to be concerned when Available hits under 300 MB; then usually pressing the kill Chromium hotkey solves the problem.

    I would love to know if there is a way to trigger the "kill Chromium" command every time the Available memory hits a certain low limit.

Note: I experimented with Zram/Zswap procedures but these didn't seem to help; these only seemed to make system overcommit freezes more often, resulting in frequent reboots (more wear on an already old hard disk, the less you reboot or suspend the better).

Winampah
  • 139
  • 4
  • I've recently upgraded hardware, new PC with 8 GB of RAM, basically double the RAM I had before. And I am surprised to be having THE SAME EXACT memory issues while using Linux, basically browsing web 95% of time, not even using heavy applications or games. There is something deeply flawed and broken at the very core of the linux kernel and the way it manages memory. I've also noticed recently that Linux will not ever free Cached memory even on situations of OOM Kernel Panic (out-of-memory) Seems like this part of the kernel was never updated from late 90's with 20 GB hard disks. – Winampah Feb 14 '22 at 02:09