Request for Fedora users with 8GB of RAM — is zram helping you?

Oh, Hey! First time posting something on the Fedora Forums. I am currently using two pcs. A desktop with GNOME, and a All-In-One with KDE.

Gnome Desktop

NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       2.9G  36M    9M  9.7M       4 [SWAP]

KDE All-IN-ONE

NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.6G   4K   74B   12K       4 [SWAP]

I really have noticed a difference on ram usage since switching to Fedora. I was a pretty frequent distro hopper but I have actually am thinking of sticking with Fedora.

Hopefully this helps you out!

4 Likes

It does, thanks. And I do hope we can convince you to stick around!

2 Likes

It seems like a really great community. I’m also looking to see into other ways I can help out.

2 Likes

I do not understand this output. Data is more than twice the size of total, so how does this get interpreted with the individual fields. At first glance it seems disksize and total should really be the only items of real concern, then the larger data item is a glaring discrepancy that I can’t seem to interpret. BTW, this is on a system with 32G RAM.

DISKSIZE is just a limit — it’s not actively being used. DATA is the raw amount of uncompressed data in swap, and COMPR is the compressed size. TOTAL is that plus overhead. From zramctl --help

Available output columns:
        NAME  zram device name
    DISKSIZE  limit on the uncompressed amount of data
        DATA  uncompressed size of stored data
       COMPR  compressed size of stored data
   ALGORITHM  the selected compression algorithm
     STREAMS  number of concurrent compress operations
  ZERO-PAGES  empty pages with no allocated memory
       TOTAL  all memory including allocator fragmentation and metadata overhead
   MEM-LIMIT  memory limit used to store compressed data
    MEM-USED  memory zram have been consumed to store compressed data
    MIGRATED  number of objects migrated by compaction
  MOUNTPOINT  where the device is mounted
1 Like
$ zramctl
NAME       ALGORITHM DISKSIZE   DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle         4G 234.5M 85.9M 88.7M      12 [SWAP]

So if I am understanding this right then total is the compressed + overhead. Data is then the total uncompressed size of all that is in swap. Yet that line in the help says “all memory” + overhead. Seems a bit conflicting since in my experience total would be ALL and here data seems to be ALL and total is a fraction of that.

1 Like

DATA is “how much would be consumed if this had not been compressed”. It is not included in TOTAL because it isn’t actually taking up that amount of memory. It is taking COMPR amount of memory.

I agree that it is a little confusing for TOTAL to mean “total memory actually used” rather than “all numbers added together”, but the latter wouldn’t be a useful number in any way while the former is.

Pragmatically, the two numbers you want to compare are DATA and TOTAL. The difference between the two is memory made free by compression.

2 Likes

Thanks @tjdoyle @mattdm
I tested it on the f33 sever and the test f34 server, and I confirmed the normal operation through the above configuration. It works well. Have a nice day!

2 Likes

Hello,
I’m on an x240 Thinkpad with 8GB of RAM, running Fedora 33 with GNOME.
Here are my results:

NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.8G   4K   74B   12K       4 [SWAP]

To be honest, i haven’t felt a difference on memory usage on that laptop between fedora 32 and 33.

Hope this helps.

2 Likes
NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.7G  3.2G  1.8G  1.8G       4 [SWAP]

This is a desktop computer. I often experience Firefox tabs crashing when running resource-intensive applications such as a rsync transfer or Virtualbox.

After you have been running for a long time and have lots of browser tabs open and other apps running

I’ll fire up VM later today and compare the results… relatively low memory-usage at the time.

1 Like

Bit late to the party but here are my figures:

NAME       ALGORITHM DISKSIZE   DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.8G 394.6M 116.3M 128.1M       4 [SWAP]

It’s a NUC (so a desktop, I guess) with 8GB RAM and running Cinnamon on F33.

Given that I’ve been running Firefox with about 20 or 30 tabs open during the couple of days since last boot, I’d say this looks pretty impressive.

Thanks Fedora :slight_smile:

Hmm,

A bit more digging, as the numbers I quoted above look too good to be true - as indeed they are on further investigation.

I have over 30 firefox tabs open currently (deliberately!) and zram shows:

/sbin/zramctl
NAME       ALGORITHM DISKSIZE   DATA COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.8G 380.2M  112M 117.6M       4 [SWAP]

But I also have an ordinary swap, as follows:

swapon
NAME       TYPE      SIZE   USED PRIO
/dev/dm-0  partition 7.7G 402.1M   -2
/dev/zram0 partition 3.8G   386M  100

Not sure whether all F33’s have an ordinary swap, or just upgrades from previous Fedora versions. However, just looking at zramctl isn’t going to give a complete picture unless you know whether there’s an ordinary swap.

I have SSD, so ordinary swap is going to be pretty fast anyway - and without knowing how zram decides when to start using the ordinary swap, it’s difficult to gauge the effectiveness of zram.

The swap on zram0 had higher priority. It is interesting that swap on dm-0 is being used when zram0 still has free space.

Hi, Since using Fedora 33 (Silverblue) I’m experiencing Firefox tabs that keep crashing after some time. I maybe have around 40 tabs open. Chromium doesn’t suffer from this but feels “slowish”

NAME       ALGORITHM DISKSIZE  DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3.8G  3.5G 951.7M 997.4M       8 [SWAP]

$ /sbin/zramctl

NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3,8G 68,4M  6,4M  7,4M       8 [SWAP]

/sbin/zramctl

NAME       ALGORITHM DISKSIZE  DATA  COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       7.5G  1.7M 484.5K  904K       8 [SWAP]

I’ve noticed that even with virtual machines opened (including windows 10) along with a bunch of browser tabs and VSCode RAM utilization never goes above 60%.

This has killed performance on my Fedora 33 Xeon box with 16G of RAM. I am annoyed that I had to go looking for this, that it didn’t show up in fstab, that swapoff -a didn’t stop swap from being reset again and again.

dnf remove zram*
systemctl stop swap-create@zram0

If you had read the documentation, even online, you could have found that zram swap would be stopped by a simple “touch /etc/systemd/zram-generator.conf” command which would have disabled the creation of zram swap at startup.

You could have even seen how to tailor it to work better for your system by “man zram-generator.conf”.

Fedora 33 had a default size of 4GB for zram and Fedora 34 upped that to 8GB but it is easy to change the defaults to whatever works for you. Fedora 33 & 34 also do not create a swap partition/file by default since they use the zram.

1 Like

Where’s the dislike button? :wink:

1 Like

Hmmm, I’m curious about that. In what way is it harming your performance? When not in use, it really shouldn’t have much impact. Do you have some numbers?