[PLASMA 5] What is eating up all this RAM????

[stratacast]

So on day...2 of Ubuntu 18.04 being released, I installed Kubuntu 18.04 on my desktop (Ryzen 1600, GTX 1070) with / on EXT4 and /home on ZFS. What I can't for the life of me figure out is where all my RAM usage is at? At the very beginning I'll be at about 1.2GB usage. Then after a couple hours it will suddenly be idling (yes, no applications opened) and be hovering at about 7GB memory used! And according to free, vmstat, and top, it will call about 2GB of that as cache. Which means, I'm having around 4GB of RAM being munched up by, what seems to be absolutely nothing. Looking at my processes in top, I can't see anything that indicates that sort of memory usage. What could possible be using up all my RAM like this? I have a hard time believing it's a cache. I say that because that would make Linux a liar when it comes to reporting memory usage.

So what's going on here? As it stands, I have to abandon Kubuntu yet again if this is the way it's going to act up on my system, and I'd much rather not do that because I am really enjoying Kubuntu 18.04 otherwise

[Rod J]

I did a quick search for "Linux ZFS memory usage" and it seems ZFS is a real memory hog. It seems to by design use as much memory as it can--

https://askubuntu.com/questions/6015...google_rich_qa

I saw this quote on another page:

"With ZFS, it's 1 GB per TB of actual disk (since you lose some to parity). See this post about how ZFS works for details. For example, if you have 16 TB in physical disks, you need 16 GB of RAM. Depending on usage requirements, you need 8 GB minimum for ZFS."

Another interesting read: https://utcc.utoronto.ca/~cks/space/...nuxMemoryWhere

Was there any particular reason you are using ZFS? I haven't heard of anyone else using it and it seems to be more designed for large servers than a home desktop/laptop as far as I can tell from a quick look online.

[stratacast]

I do know that ZFS uses a lot of memory, but if it is in fact ZFS, Linux must report its memory usage differently than FreeBSD, because I have a FreeBSD server with 7 running jails and a 4TB zpool and it's using 2GB RAM and the other 14GB is cache, where with Kubuntu if it is ZFS caching, it's certainly reporting differently (I have a 2TB disk) and even with the "1GB RAM per 1TB" I still think there's unaccounted for memory usage.

My initial reason was going to simply be frequent scrubs to at least be able to check for potentially corrupted data as well as data snapshots, and one day in the future possibly turn my /home dir into a ZFS mirror for redundancy and error correcting. I'm finding whatever ZFS on Linux does though is really...bizarre in how it does snapshots. I.E. - if I create a snapshot in the zfs dataset I can't just see the snapshot in the .zfs directory, even though it's there. But that's beside the point

[GreyGeek]

ZFS cannot be used as the root file system, so you have to install /boot on an EXT4 partition. That's its first major weakness. Second is the RAM requirements, as Rod J pointed out. The third is how snapshots are saved.

The solution is to re-install Kubuntu 18.04. During the install select the HD you are going to install on and make sure that it has only one, say, sda1. Install Kubuntu on sda1. After selecting sda1 select Btrfs in the dropdown combo box that has EXT4 preselected. Give that partition the label "/" and continue on with the installation.

When you are done you will have Kubuntu 18.04 running with Btrfs as the root file system. It has all the power of ZFS but none of the licensing issues. It also allows you to create multiple snapshots that are independent of previous or subsequent snapshots and each @ or @home combo can be reverted to when ever you wish. You can do all of this while your system is running and you are using it!

There are several GUI interfaces to Btrfs. One is snapper. Another is Btrbk. A third is apt-btrfs-snapshot, which is similar to snapper.

I've tried most, and they can be configured to do pretty much what you want, but I reverted to manually making backup snapshots and restoring them because it is so easy. Another reason why I choose this way is because it allows me to place my snapshots at the "Root_FS" level, outside the running system, and not accessible to them during normal operations, as the snapshots make by snapper, btrbk and apt-btrfs-snapshots are.

Oshunluver has great tutorials on this forum about btrfs.

[stratacast]

ZFS cannot be used as the root file system, so you have to install /boot on an EXT4 partition. That's its first major weakness. Second is the RAM requirements, as Rod J pointed out. The third is how snapshots are saved.

The solution is to re-install Kubuntu 18.04. During the install select the HD you are going to install on and make sure that it has only one, say, sda1. Install Kubuntu on sda1. After selecting sda1 select Btrfs in the dropdown combo box that has EXT4 preselected. Give that partition the label "/" and continue on with the installation.

When you are done you will have Kubuntu 18.04 running with Btrfs as the root file system. It has all the power of ZFS but none of the licensing issues. It also allows you to create multiple snapshots that are independent of previous or subsequent snapshots and each @ or @home combo can be reverted to when ever you wish. You can do all of this while your system is running and you are using it!

There are several GUI interfaces to Btrfs. One is snapper. Another is Btrbk. A third is apt-btrfs-snapshot, which is similar to snapper.

I've tried most, and they can be configured to do pretty much what you want, but I reverted to manually making backup snapshots and restoring them because it is so easy. Another reason why I choose this way is because it allows me to place my snapshots at the "Root_FS" level, outside the running system, and not accessible to them during normal operations, as the snapshots make by snapper, btrbk and apt-btrfs-snapshots are.

Oshunluver has great tutorials on this forum about btrfs.

You're right, ZFS on root does not work with Linux, I do have EXT4 as /, I see I didn't specify that. I used to run BTRFS but haven't had the itch to switch back to it, I end up putting my data on XFS partitions and leave / as EXT4. Does BTRFS still have the issue where you can't have the /boot partition as BTRFS? I'll also think about snapper, I remember that being a neat tool on OpenSUSE. I think worst case scenario, if ZFS is being really bad with my memory on Linux, I may switch my /home back to XFS or maybe BTRFS

[oshunluvr]

Does BTRFS still have the issue where you can't have the /boot partition as BTRFS?

No and hasn't for quite a while. I even have my stand-alone grub partition in a subvolume. I did discover that grub does not support the new ZSTD compression yet so stick to LZO is you use compression.

[GreyGeek]

You're right, ZFS on root does not work with Linux, I do have EXT4 as /, I see I didn't specify that. I used to run BTRFS but haven't had the itch to switch back to it, I end up putting my data on XFS partitions and leave / as EXT4. Does BTRFS still have the issue where you can't have the /boot partition as BTRFS? I'll also think about snapper, I remember that being a neat tool on OpenSUSE. I think worst case scenario, if ZFS is being really bad with my memory on Linux, I may switch my /home back to XFS or maybe BTRFS

No, that issue is moot. I've been using Btrfs for 3 years and have never had to install /boot on a non-btrfs partition. In fact, you should checkout oshunluver's configuration for his six distros on one HD setup. I've configured Btrfs to install on both sdX and sdX1. There is divided opinion on the merits of both, but I never had problems with either. Because I am more agreeable with the sdX1 (sda1) arguments I prefer that location, letting the install program put the boot load where it wishes.

I started with one 750Gb HD in my laptop and gave Btrfs /dev/sda1. When I bought an HDCaddy to replace my CDROM I found I had two HD bays (Acer V3-771G)! So, I put the 2nd 750Gb HD in the second bay. I used Btrfs to change from SINGLE to RAID1 using Btrfs balance and making data, metadata and system RAID1. Of course, I did it while running the system live. Later, I added another 750Gb HD using the HDCaddy. When I did that I found out why the UUID is recommended instead of /dev/sdXn. My sdb1 (part of the RAID1) became sdc, and the 3rd drive became sdb1, my archive drive. The RAID1 was now sda1 + sdc. Things continued to work well but I kept getting occasional warnings about the two drives having the same part-by-id path, or something like that -- I've forgotten exactly what the warning was. Later, I reverted the RAID1 to SINGLE for both drives and made them both part of my system pool, in order to increase available space. All done while running the system live. The only time I had to run from a LiveUSB was when I wanted to run btrfs check. With all my jacking around with my system the check gave a clean bill of health.

As far as continuing to use ZFS, one solution, of course, is to jack up your RAM! (I know, I can't afford that either!)

Snapper is a nice tool. One MUST change the default configuration, however, or it won't take long for the number of snapshots to blow out your HD space. The main thing I don't like about snapper and the rest is that they create their snapshot directories inside / and /home, making them impossible to reach IF @ becomes unbootable or inaccessible. That's why I like to open a root Konsole and

sudo -i
:~# mount /dev/disk/by-uuid/47a4794f-b168-4c61-9d0c-cc22f4880116  /mnt
root@jerry-Aspire-V3-771:~# vdir /mnt
total 0
drwxr-xr-x 1 root root 262 May 22 13:58 @
drwxr-xr-x 1 root root  10 May  3 23:06 @home
drwxr-xr-x 1 root root 144 May 22 13:55 snapshots
root@jerry-Aspire-V3-771:~# vdir /mnt/snapshots/
total 0
drwxr-xr-x 1 root root 206 May  4 09:11 @_20180507
drwxr-xr-x 1 root root 256 May  9 10:22 @_20180512
drwxr-xr-x 1 root root 262 May 14 22:39 @_20180522
drwxr-xr-x 1 root root  10 May  3 23:06 @home_20180507
drwxr-xr-x 1 root root  10 May  3 23:06 @home_20180512
drwxr-xr-x 1 root root  10 May  3 23:06 @home_20180522

I modified snapper's config to make only singles and wrote a bash script that created a "PRE" and "POST" SINGLE to make a snapshot before I do something and after I do it. Then I could use snapper's command to roll-back to a previous single of a pair. But, they still suffered from the "not on par with @ and @home" problem.
However, if what you do changes both root and home then you have to roll them both back, and to the same point. It was just a lot easier to do it manually using "/mnt" as the "Root_FS", and each snapshot is independent of any other. That lack of independence is a problem with ZFS snapshots. If you roll back to a previous and particular snapshot then any snapshot taken after that point is lost. With Btrfs, I can roll back to 20180512 without losing 20180522.

Like I've written many times on this forum, and yet again , I won't use a distro that doesn't allow me to use Btrfs as the root file system. What I haven't said so often is that I won't use openSUSE because they make TOO MANY subvolumes during installation. Just about every directory under "/" has been made a subvolume. IMO that is overkill.

[stratacast]

Like I've written many times on this forum, and yet again , I won't use a distro that doesn't allow me to use Btrfs as the root file system. What I haven't said so often is that I won't use openSUSE because they make TOO MANY subvolumes during installation. Just about every directory under "/" has been made a subvolume. IMO that is overkill.

I actually did in fact see you write this the other day I was sold on btrfs for some time too, ended going to XFS because I wasn't utilizing its features and at the time I heard enough "data gone" stories, also at the time systems would fail to boot with /boot being btrfs, so it turns out my experience with the FS is outdated already Perhaps to restore my vanishing memory I'll have to go back to btrfs...would be a great thing for doing Borg backups from my snapshots vs data I'm actively working on! I've come to like snapshots for that reason alone. I think I'll keep / as EXT4 though because I've done enough distro hopping to get to this point (long story of short support cycle distros and other unstable ones), if butter can make my memory usage "normal" again, I'll be happy. All my other pooters and servers are good, time to get my main workstation in the same place

EDIT: forgot to add - I'll update on whether or not switching to btrfs was the solution or not, but will probably be late next week (around June 1) when I update, will be on vacation

[kc1di]

Great info on file systems some one knowledgeable should do a wiki or writeup of some sort as it relates to Kubuntu/KDE -- Will book mark this thread.

[GreyGeek]

Oshunluver has some GREAT threads on Btrfs as it relates to Kubuntu.