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 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


      • Originally posted by aht0 View Post
        It might have been not "FreeBSD's problem" but fault in it's ZFS driver.
        Most likely the latter, FreeBSD has a OOM killer just like Linux, their approach to "not enough RAM" is the same.

        Comment


        • The stalling problem has been going on for at least 8 years. Ive noticed it as long as that. It happens with non ZFS systems.

          I think it has something to do with maybe the paging system, allocation, perhaps i/o scheduling or process scheduling getting caught in some sort of a lock up. If you can manage to get some control killing a big process usually fixes the problem, but I have doubts that it is a just problem with processes not being killed instead the memory situation triggering some other bug that causes thrashing and lock up.

          the LED lights up solidly as mentioned and the system becomes unresponsive and will remain so for hours.

          This is not acceptable and also should be categorized as a security vulnerability as this is a DENIAL OF SERVICE vulnerability as someone can bring down a system by causing these pressures. This is a very serious problem and the Linux kernel developers clearly do not care that Linux can be brought down.

          A way to improve Linux would be to allow default OOM behaviour to be augumented by allowing an external process to be notified of an OOM condition and decide what processes should be killed to free up memory, this can be configured to ask the user or to use a list of processes to kill and or a list of ones to be left alone. Monitor could use another API to know when the OOM system is satifisfied enough memory has been freed. Another feature is memory priority that X, console programs would have high memory priority and they would get access to being paged into memory so they can remain responsive , while other process may be suspended while memory is freed. On a desktop machine killing firefox usually suffices because this is the big memory consumer. X and other critical processes have to be left alone so there will still be a running machine.
          Last edited by Neraxa; 08-11-2019, 02:10 PM.

          Comment


          • Many have suggested this is caused by disabling swap however I have seen it with gigabytes of swap enabled and with most of the swap space being unused. What brings it on is things coming to within 200 MB or so of running out of RAM space. Its usually Firefox, and killing Firefox unlocks the system (it can take hours to actually get that done considering the system is in a virtually locked up state). The OOM killer is obviously not getting rid of Firefox itself, it would not obviously since there are gigabytes of swap still free. So, it kind of looks like the OOM killer is not even involved here since there is plenty of swap space available/. Looks like could be a problem involving i/o scheduling, allocation, process scheduling or something.
            Last edited by Neraxa; 08-11-2019, 08:10 PM.

            Comment


            • Originally posted by Neraxa View Post
              Many have suggested this is caused by disabling swap however I have seen it with gigabytes of swap enabled and with most of the swap space being unused. What brings it on is things coming to within 200 MB or so of running out of RAM space. Its usually Firefox, and killing Firefox unlocks the system (it can take hours to actually get that done considering the system is in a virtually locked up state). The OOM killer is obviously not getting rid of Firefox itself, it would not obviously since there are gigabytes of swap still free. So, it kind of looks like the OOM killer is not even involved here since there is plenty of swap space available/. Looks like could be a problem involving i/o scheduling, allocation, process scheduling or something.
              On my 16 GB laptop w/o swap where I do everything from multimedia to sw development to web browsing with FF and 20+ tabs open I haven't experienced any of the issues mentioned here. But if the default OOM killer is too slow, what about the already mentioned earlyoom or nohang (both with support for psi), or facebook's oomd - anybody tried them in these situations?
              Last edited by halo9en; 08-12-2019, 09:31 AM.

              Comment


              • I just tested this on FreeBSD 12. When a process hits the memory cap it instantly prints pid num, process name, uid num, was killed: out of swap space. Using moused to move the mouse around it doesn't even hickup. It took me less than 10 minutes to test this.

                FreeBSD's oom killer isn't very advanced but there is value in simplicity. This just works.. I know someone is out there writing a huge user land daemon to fix this.. But you don't need systemd-oombandaid. In fact the reason Linux is thrashing the disk is probably system-journal.

                Comment


                • Well I have something that works for me(ie. no disk thrashing), but only made it today(so not tested much) and that is a kernel patch(le9g.patch) to not evict `Active(file):`(see /proc/meminfo) if below 256 MiB (this should depend on your workload). I've tested it with linux-stable 5.2.4 because on linuxgit 5.3.0-rc4-gd45331b00ddb there's a yet-to-be-found-regression that freezes the whole system(without disk thrashing though) whether I use the patch or not, apparently before OOM-Killer would trigger.

                  Code:
                  diff --git a/mm/vmscan.c b/mm/vmscan.c
                  index dbdc46a84f63..7a0b7e32ff45 100644
                  --- a/mm/vmscan.c
                  +++ b/mm/vmscan.c
                  @@ -2445,6 +2445,13 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
                               BUG();
                           }
                   
                  +    if (NR_ACTIVE_FILE == lru) {
                  +      long long kib_active_file_now=global_node_page_state(NR_ACTIVE_FILE) * MAX_NR_ZONES;
                  +      if (kib_active_file_now <= 256*1024) {
                  +        nr[lru] = 0; //don't reclaim any Active(file) (see /proc/meminfo) if they are under 256MiB
                  +        continue;
                  +      }
                  +    }
                           *lru_pages += size;
                           nr[lru] = scan;
                       }

                  Comment


                  • Originally posted by howaboutsynergy View Post
                    Well I have something that works for me(ie. no disk thrashing), but only made it today(so not tested much) and that is a kernel patch(le9g.patch) to not evict `Active(file):`(see /proc/meminfo) if below 256 MiB (this should depend on your workload). I've tested it with linux-stable 5.2.4 because on linuxgit 5.3.0-rc4-gd45331b00ddb there's a yet-to-be-found-regression that freezes the whole system(without disk thrashing though) whether I use the patch or not, apparently before OOM-Killer would trigger.

                    Code:
                    diff --git a/mm/vmscan.c b/mm/vmscan.c
                    index dbdc46a84f63..7a0b7e32ff45 100644
                    --- a/mm/vmscan.c
                    +++ b/mm/vmscan.c
                    @@ -2445,6 +2445,13 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
                    BUG();
                    }
                    
                    + if (NR_ACTIVE_FILE == lru) {
                    + long long kib_active_file_now=global_node_page_state(NR_ACTIVE_FILE) * MAX_NR_ZONES;
                    + if (kib_active_file_now <= 256*1024) {
                    + nr[lru] = 0; //don't reclaim any Active(file) (see /proc/meminfo) if they are under 256MiB
                    + continue;
                    + }
                    + }
                    *lru_pages += size;
                    nr[lru] = scan;
                    }
                    Noice!

                    Now it would be even greater if it either were a tunable parameter (via sysctl) or computed based on the amount of installed RAM.

                    Comment


                    • "..Linux Does BadLY ...". Love ye Michael, but your grammar is better than that.

                      Comment

                      Working...
                      X