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

  • Swap only delays this issue, you will run into the same problems when the Swap gets compltely filled up.

    Comment


    • Originally posted by birdie View Post

      I've just installed it ;-)

      The issue we are arguing about is that (some of) its functionality must be built into the kernel itself to avoid complete stalls for up to hours.
      OOM killing is hard to generalise, and the memory pressure indicators are hard to interpret. Not only is earlyoom likely to be the fix that desktop users are looking for, it will be an early adopter of PSI stats once someone works how to use them in the general case, so that's another reason to follow it. Meanwhile, the discussion around the project is more more informed. It is astounding that so few people know about it. I could understand if people reported that it didn't work, but actual knowledge of the tool seems close to zero. https://github.com/rfjakob/earlyoom
      I tried killing a 4GB VM ... it is not too hard to get the kernel to deal badly with the situation. I could not kill the same machine when earlyoom was running. swap made no difference either way, of course; swap advocates are barking up the wrong tree if they think swap settings can save the kernel's OOM reaction.
      Last edited by timrichardson; 08-07-2019, 08:09 AM.

      Comment


      • There should be userspace daemon for this like in Android. However, "desktop" part of Linux is busy with removing features and braking userspace all the time. It amazes me how Linux kernel developers care about not breaking compatibility while "desktop" does it every time. I hope Valve comes with sane distribution and ends this madness.

        Comment


        • I had hope I won't see posts coming from birdie, but damn it. What's worth to note installing game on Steam makes Windows crawl.
          Last edited by tildearrow; 08-07-2019, 05:33 PM.

          Comment


          • Originally posted by skeevy420 View Post

            It's exactly how I'd expect it to behave.

            A system with the memory all used up and no swap space available runs like shit...you don't say...
            No, it should not. It should handle the situation gracefully, not cause the entire system to lock up. If the system locks up, thats a major bug. There is simply no reason for it.

            If memory is exhausted, the most critical processes have to be protected such a X.org, audio servers, etc, so there should be away to immunize certain processes from being killed. Another possibility is to implement an epoll interface allowing a monitor program to be notified if system is out of memory and throw up a dialog to the user asking which process should be killed. There is no reason at all for a system to just lock up except that it is designed in a totally incompetent manner by people who dont know what they are doing. Its been doing this for ever and Linux runs like an unstable crap OS that makes Windows shine by comparison. Its been this way for over 10 years. Its just appalling and infuriating that it takes so long to get the kernel people to do anything about it, showing again that nobody cares about desktop users.

            Comment


            • Originally posted by timrichardson View Post

              OOM killing is hard to generalise, and the memory pressure indicators are hard to interpret. Not only is earlyoom likely to be the fix that desktop users are looking for, it will be an early adopter of PSI stats once someone works how to use them in the general case, so that's another reason to follow it. Meanwhile, the discussion around the project is more more informed. It is astounding that so few people know about it. I could understand if people reported that it didn't work, but actual knowledge of the tool seems close to zero. https://github.com/rfjakob/earlyoom
              I tried killing a 4GB VM ... it is not too hard to get the kernel to deal badly with the situation. I could not kill the same machine when earlyoom was running. swap made no difference either way, of course; swap advocates are barking up the wrong tree if they think swap settings can save the kernel's OOM reaction.
              early killing would help, I would also recommend having an epoll event API for an external monitor program to be notified early of an OOM event and then can throw up a dialog to ask the user which process to kill, certain processes that are critical have to be protected like X , window manager, etc. Can be user configurable to automatically kill processes or to ask. Monitor program could be configured by user to go after certain processes in particular firefox first and to leave critical processes alone. Another possibility is a reserved memory space for near OOM conditions which allow critical applications to keep on using that memory and allow the user to have a responsive system to be able to use the dialog to kill a process.

              I wonder if killing is not the only issue, the problem has felt like some sort of bug in the scheduling system or interaction between allocation, i/o scheduling and process scheduling which causes the lockups. An OOM condition should never cause a lock up.

              Comment


              • Originally posted by dnebdal View Post
                Not at all - which would you rather debug?
                "The production DB server became super slow and caused everything else to fail strangely for several hours until someone manually rebooted the VM", or
                "The production DB server died, there is an easy to understand OOM message in the logs, and since it stopped completely it was immediately restarted by a monitoring service".
                The memory reclaim, feature doesn't work very well..
                probably will be there tons of GB of pagecache, that can be reclaimed, but usually they are not( Linux do favour speed over resources, prefer to continue caching, until the system dies, but it works better now than in the past, but still insufficient.. )..

                first you should drop your speedup caches,
                Which will lead to more ram available, in that way, you can work, it will increase IO to access data, but better that, than kill the entire stack..
                Limit the number of sessions, when you are recovering, then probably you will need to kill some session that is doing something nasty..
                Workout a better 'limits.conf', enforce Soft and Hard-Limits..

                Rebooting complex stacks is not a so simple task, and is not the answer

                Comment


                • Originally posted by tuxd3v View Post

                  The memory reclaim, feature doesn't work very well..
                  probably will be there tons of GB of pagecache, that can be reclaimed, but usually they are not( Linux do favour speed over resources, prefer to continue caching, until the system dies, but it works better now than in the past, but still insufficient.. )..

                  first you should drop your speedup caches,
                  Which will lead to more ram available, in that way, you can work, it will increase IO to access data, but better that, than kill the entire stack..
                  […]
                  This is precisely what the kernel does right now and what causes the kind of problem the article describes when the entire working set is evicted from the cache.
                  Last edited by archkde; 08-07-2019, 08:50 AM.

                  Comment


                  • Originally posted by Volta View Post
                    There should be userspace daemon for this like in Android. However, "desktop" part of Linux is busy with removing features and braking userspace all the time. It amazes me how Linux kernel developers care about not breaking compatibility while "desktop" does it every time. I hope Valve comes with sane distribution and ends this madness.
                    With the recent 32 bit removal, which is a disaster, its time valve should just get into making their own distro, based on Ubuntu or Fedora of course, but with no more of these stupid anti-desktop moves, creating unuseable user interfaces like Gnome, breaking backward compatability, or other anti-desktop user movies. a desktop distro should fully support 32 bit only installs, should have a strong focus on backward compatability, desktop apps like gaming and desktop publishing. It should have a feature rich window system that allows the user to configure everything through GUI configuration tools, rather than treat the user like an idiot. I want settings and configurability. Its hard to figure out how to even change the color scheme on Gnome.

                    I get the feeling that Fedora/Red Hat and Ubuntu absolutely hate their desktop users and do everything they can to throw water in their faces and especially with this 32 bit removal move which is really a stab at desktop users.
                    Last edited by Neraxa; 08-07-2019, 09:01 AM.

                    Comment


                    • Originally posted by Neraxa View Post
                      . There is no reason at all for a system to just lock up except that it is designed in a totally incompetent manner by people who dont know what they are doing. Its been doing this for ever and Linux runs like an unstable crap OS that makes Windows shine by comparison. Its been this way for over 10 years. Its just appalling and infuriating that it takes so long to get the kernel people to do anything about it, showing again that nobody cares about desktop users.
                      No you are wrong, it's not about [in]competence, they don't give a sh%t about OS stability. They do not care, the problem persist from many, many years.
                      No differences if booting from a optical media, LIVE CD or HDD. Or from floppy drive . OOM cand do nothing, because it's more a I/O problem, a constant bottleneck. Neither applications don't do too well, don't seem to shine in this regard [concurrent I/O management far from having a good implementation]. Some type of concurrent I/O, on spinning magnetic drives, freeze/lock UI doesn't matter which DE is used KDE, XFCE, LXQT etc, or distribution ...

                      Comment

                      Working...
                      X