On Mon, Jun 21, 2021 at 1:25 PM Samuel Sieb <samuel@xxxxxxxx> wrote: > > On 2021-06-21 1:05 a.m., Bill Shirley wrote: > > The server is running on Raid-1 SSDs with 64GB of RAM > > > > Bill > > > > On 6/21/2021 3:41 AM, Samuel Sieb wrote: > >> On 6/20/21 7:25 PM, Bill Shirley wrote: > >>> One of the first things I did after installing F34 is disable > >>> swap-on-zram: > >>> touch /etc/systemd/zram-generator.conf > >>> and define a swap partition in fstab. > >> > >> Why? > > I don't see how that's an answer to why you would disable zram. > Especially when your later reply shows that you're not really even using > the disk swap anyway. Lots of folks don't realize that zram devices don't use any memory (small amount of overhead based on the size of the zram device, and driver; less than 0.1% of the zram device size), and that it's dynamically allocated. But it's true that swap efficacy as a percentage cannot be 100% like it is with disk or file based swap. That it's so much faster makes up for the lower efficacy. By that I mean, a 4 KiB page being swapped out to disk means you free 4 KiB RAM and consume 4 KiB on disk. With zram based swap, it's still memory, but it's compressed. So you free up 4 KiB uncompressed memory for other things; and you consume ~2 KiB RAM for that compressed page in the zram device. The efficacy is related to the compression ratio you get, which is anywhere 2:1 to 3:1. So it's an efficacy of 50% to 75%. For sure it's better than no swap which has an efficacy of 0% :) In fact that's misleading because when a system can't evict dirty pages at all, it's forced to do file page reclaim, i.e. libraries, executables, configurations that exist as files on disk, can be removed from memory via reclaim, because they're already on disk and can just be read back in. But when under memory pressure, reclaim can look a lot like swap thrashing and even compete with it. So some swap is better, and also due to SSDs, we're probably better off with a higher swappiness value, i.e. give equal weight to page out of anonymous pages as reclaim. But some workloads are different and you can actually get a kind of in-memory swap thrashing same as on disk. It's so fast that it's normally not a problem. Until it is. So we definitely want to keep an eye on reports of folks having issues that sound like hangs or lockups, any time the desktop becomes unresponsive we want to find out what's going on First thing to check in those cases is if the system is running uresourced. It's only enabled by default on GNOME right now. But it's considered safe to run as an opt in for other desktops, though we want to keep an eye on possible regressions. There is still more work to do in this area, in particular wiring up the IO isolation. Any time there's memory pressure it'll quickly lead to IO pressure: reclaim and swap. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
