Announcement

Collapse
No announcement yet.

Yes, Linux Does Bad In Low RAM / Memory Pressure Situations On The Desktop

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by starshipeleven View Post
    You are a moron.

    A system with memory used up and no swap available is supposed to run the OOM killer to "sacrifice children" (actual error message it prints in the dmesg), killing non-critical processes to stay functional and responsive, so that someone can actually do something about it.

    I can't go in and fix shit if the GUI does not work, or if SSH is unresponsive.

    On anything remotely new I always had to run without swap partition to have the OOM killer wake up and do its job, if I leave swap the system will start swapping like crazy and lock down everything even on a SSD.
    I also think that a big part of the problem is how damn near every process runs with 0 and there really isn't any good solution for that; like all programs into their own group and using group policies, aliasing programs and append a nice/renice function to them, and other similar fustercluck solutions.

    When the kernel is in an OOM situation and is also being told that everything is equal, that can make it more difficult for it to decide what to kill and what not to kill. That's where some sort of user-level monitor would come in handy (which is what a lot of Android methods do) because that's a lot easier for most people to use and figure out, some sort of save state method that can cache a program to disk and kill it off like others have suggested, use lots of nice levels and killing of higher numbers first.

    Comment


    • Originally posted by elatllat View Post

      Code:
      > mount | grep -c cgroup/memory
      1


      Code:
      > sudo systemd-run -p MemoryMax=512M /usr/bin/sudo -u $USER env DISPLAY=:0 chromium-browser --user-data-dir=/home/$USER/.config/chromium/
      
      > group_mem.sh chrom
      1,045 MB chromium-browse
      
      > systemctl show run-r4c138899383242ad9f92331b51d24c41.service | grep -i Memory
      MemoryCurrent=[not set]
      MemoryAccounting=no
      MemoryLow=0
      MemoryHigh=infinity
      MemoryMax=536870912
      MemorySwapMax=infinity
      MemoryLimit=infinity
      MemoryDenyWriteExecute=no
      Maybe you should try before you recommend.
      I think I'll try cgroup_enable/cgcreate/cgexec next
      there needs to be a -E to pass an environment variable

      Code:
       -E --setenv=NAME=VALUE Set environment

      Comment


      • Originally posted by tildearrow View Post

        Please don't bring the Windows mentality of "if it doesn't work well, bring better hardware" to the Linux world.
        As an example, Linux makes an HDD look fast, while Windows needs an SSD to be fast.

        Also, please note that this was in 2015 when I only had 8GB RAM in my system. I then upgraded to 16.
        (This still occurs with my dad's 1GB laptop, however, and we'd love to fix it but sometimes we have fights and not enough money which distances us from the solution)
        Linux uses memory extremely well. Not giving machine proper amount of ram, is like putting Reno engine in half million Ferrari.
        Now I won't disagree that things can improve. But getting frustrated over switching off RAM is like throwing shovels around and play hide and seek with eyes shut.

        Comment


        • Originally posted by elatllat View Post
          [...]
          Maybe you should try before you recommend.
          Of course I tried.
          It works very well for me. Have a look.
          https://drive.google.com/file/d/1Tov...ew?usp=sharing (I'm not sure if Google servers have processed the video, you can always download.)

          Maybe it's time to update your Linux to a much newer (more modern) version.

          Comment


          • Originally posted by latalante View Post
            Of course I tried.
            It works very well for me. Have a look.
            https://drive.google.com/file/d/1Tov...ew?usp=sharing (I'm not sure if Google servers have processed the video, you can always download.)

            Maybe it's time to update your Linux to a much newer (more modern) version.
            One of the many differences from Ubuntu to Arch must be to blame.

            "cgroups-v2 first appeared in Linux kernel 4.5" [src]

            I only use rolling distributions occasionally in VMs, otherwise I stick to LTSs;

            Code:
            > uname -r
            4.15.0-55-generic
            
            > lsb_release -r
            Release:    18.04
            
            > systemctl --version | head -n 1
            systemd 237
            
            > mount | grep -P "cgroup2|memory"
            cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
            cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
            I wonder if Ubuntu is using a strange mix of v1 and v2...





            Comment


            • Originally posted by elatllat View Post

              One of the many differences from Ubuntu to Arch must be to blame.

              "cgroups-v2 first appeared in Linux kernel 4.5" [src]
              What I have shown works under Archlinux.
              Kernel booted with a parameter:
              systemd.unified_cgroup_hierarchy=1

              Comment


              • Originally posted by skeevy420 View Post
                When the kernel is in an OOM situation and is also being told that everything is equal, that can make it more difficult for it to decide what to kill and what not to kill.
                Is it? A naive approach that solves probably 99% of the problems would be to just kill the process consuming the most memory. Some slightly less naive but also more complicated approach could be to measure the speed a process grows and kill the one that grew the most in the last second. That should be pretty accurate in killing of "leaks".

                Comment


                • Originally posted by aht0 View Post

                  Bullshit, BSD (FreeBSD at least) may kill one or few memory-hogging programs, system may become sluggish but running out of RAM does not make it crash. Been there, tried that.
                  Leave an apologist to try and find some angle tho..
                  Ok, so it was added somewhere after 2015 then, quite recent I'd say. Either way, back in the day they said that oom killing was wrong and crashing was the right thing to do.

                  Would have been a better post if you could say when it was added instead of being a smarty-pants about it.

                  Comment


                  • Originally posted by skeevy420 View Post
                    I also think that a big part of the problem is how damn near every process runs with 0 and there really isn't any good solution for that; like all programs into their own group and using group policies, aliasing programs and append a nice/renice function to them, and other similar fustercluck solutions.
                    Yeah, Linux distros are still in the server mindset of not giving priorities or niceness to processes that should really gtfo and stop lagging the system, but in this case it is mostly tangential.

                    The OOM killer already takes RAM usage into consideration, so even if all processes have same priority the bigger one will get axed first.
                    https://unix.stackexchange.com/quest...-to-kill-first

                    Comment


                    • Originally posted by pomac View Post

                      Ok, so it was added somewhere after 2015 then, quite recent I'd say. Either way, back in the day they said that oom killing was wrong and crashing was the right thing to do.

                      Would have been a better post if you could say when it was added instead of being a smarty-pants about it.
                      It might have been not "FreeBSD's problem" but fault in it's ZFS driver. And "smarty-pants"..? Then please don't put up idiotic comments. Starting with putting all BSD's into one kettle. Each is distinct operating system with IT'S OWN kernel, not like Linux distros, which all are using single kernel and differ only in what's put "around it". Thus it's likely that all behave different in any given scenario because forkings happened decades a go and lot's have changed in each meanwhile. You just can't generalize like that or it would make you look like an fanatic idiot. And I went "smarty-pants" based on that: such assumptions simply won't deserve any other response than response on same level.

                      Comment

                      Working...
                      X