On Sun, Nov 10, 2019 at 8:42 PM Code Zombie <codezombie724@xxxxxxxxx> wrote: > > > Hi, > I recently installed a fresh Fedora 31 in order to improve performance. I have started to have a new problem. When my memory fills up when launching an Android emulator, the system starts acting very slowly and becomes quite unresponsive. I used to fill both memory and swap close to 100% without much degraded performance, but now I wonder if there has been some changes in Fedora memory management causing this? And after all that, once I close the emulator and free up some memory out of the total 8GB physical, the computer starts to breathe again and back to normal. This is related to this devel@ list discussion topic: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/ Which is an extension of this Workstation working group issue: https://pagure.io/fedora-workstation/issue/98 Basically, I still have more questions than answers. But I look forward to having something testable. What I can tell you from many conversations I've been having on this subject: - the kernel's swap is historically only intended for incidental swap use, i.e. light writes to offload seldom used data to a backing device in order to free up memory for actively used data - due to default 1:1 ratio RAM to swap partitioning layouts, and increased RAM in systems, swap has grown very large, but the bandwidth to either HDD or SSD swap hasn't kept up. So in the non-incidental variety of swap use we're increasingly seeing with VM and compile use cases, swap thrashing is more common. That is, a persistent and aggressive (high rates of read and/or writes to/from swap). And this is where swap really fails because everything becomes IO bound in the course of swap thrashing. - It's completely reasonable for users to wonder WTF is going on, when their system appears to have faceplanted even for 15 seconds. While it's true the best solution is to add more physical RAM, it's common for hardware to lack any ability to upgrade RAM after purchase. - Some forms of compressed swap, both swap on ZRAM (entirely RAM based, no backing swap partition), and ZSWAP (both RAM caching and disk backed) can help smooth the terribly abrupt transition from RAM only to swap dependent operations. The catch here is that under heavy load, both of these become CPU bound due to compression/decompression, as well as IO bound. It definitely helps moderate the badness of swap use, but it's not a cure. - The in-kernel out of memory manager (oom-killer) does not at all care about user space. It doesn't care about responsiveness or interactivity at all. It only cares about itself, and keeping its own directly owned kernel threads running. When low memory threatens the kernel, is the only time you'll see the kernel oom-killer clobber a process. While this is tunable, it's really limited, and more often than not in the current configuration you will see random processes get killed off, not necessarily the worst offending processes. - the above two combined translate into strategies to avoid swap usage, and quickly kill top memory offenders within seconds, instead of minutes, in order to give the impression of continued system responsiveness. Of course, what's really happened is a process is being killed off in order to achieve that. My suggestion is to reproduce the problem, and capture a few bits of information and post them to this thread: $ free -m $ cat /proc/meminfo $ swapon You might consider disabling your swap partition in /etc/fstab, by just commenting out that line, shutting down all processes you've got running or even just log out and then back in: # swapoff /dev/sdXY # dnf install zram # systemctl enable --now zram I've modified /etc/zram.conf to use FACTOR=1 which has worked out well. Again, not panacea, and it depends by how much you're pressuring swap, but this might alleviate some of the problem if your use case is extremely swap IO bound, by exchanging it for CPU and RAM effort. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
