Doh. I missed the df -h part, anyhow here you go,
Also, updated the original post with some observations (see Edit 1)
Hmm, it seems to rule out lack of available space. Too bad, I like easy solutions.
Itâs a bit strange that swaps grows so much while you still have lot of free memory. Memory management as reported by Linux tools is tricky, though.
Itâs not obvious that there is a lot of people with the same kind of load; I am sure that there are a lot of professionals using LXD with big containers, but this kind of people tend to stick to LTS version and are unlikely to use SNAP version. And lxc export donât work with LTS versions. So itâs not unthinkable you have hit a problem no one has seen before.
Maybe there is a more exotic limit somewhere; I donât know about snap itself, donât think there is a limit, but maybe in Zfs ? not set any quota ? Iâd say that export should involve a Zfs snapshot, and snapshots take space.
Before opening an issue on Github, I think it would be good to be sure that there is no remnant of a prior crash before trying a new test. Like I said in this comment I am not sure where and when the data is cleaned. Possibly waiting a bit (not kidding, I have a vague remembering of reading somewhere in the code that there is some sweeper periodically triggered) and restarting host.
Possibly you could try create another Zfs volume, duplicate your container in it (with a good deal of free space, without any quotasâŚ) and do an export of this copy. Just a thought, but since you have plenty of free space it seems it could be done.
- Swap slowly increased continuously (end up eating 1.05 GB out of 2 GB).
Got the same issue here but doesnât stop and consumes everything.
- RAM consumption also increased from average of 6 GB to 10 GB (total is 16 GB) but never went past that mark.
But then for me it went back from average of 10 GB to 1 GB. And naturally then the whole OS nearly goes to a full stop. Have to reboot by force.
I also use LXC 3.11 as a snap package.
Weird AF.
Iâve found the most reliable way to backup to a file if using zfs as backend storage is with zfs send.
I have this cobbled together script which works nicely for me.
#!/bin/bash
# set echo on
set -x #echo on
container=$1
backupdir=/mnt/backups/lxd
cd $backupdir
/sbin/zfs destroy zfs1/containers/$container@snapshotBackup
/sbin/zfs snapshot zfs1/containers/$container@snapshotBackup
/sbin/zfs send zfs1/containers/$container@snapshotBackup | /usr/bin/mbuffer -q -m 2000M | /usr/bin/pigz -c -p 8 | /usr/bin/mbuffer -q -m 2000M > $backupdir/$container.gz
/sbin/zfs snapshot zfs1/containers/$container@snapshotBackupI havenât really found a solution to this problem yet but as a workaround (and maybe a better practice), I have started using storage volumes instead. All the application related data (in this case nextcloudâs data dir) gets saved to storage volumes and container itself remains barebones carrying nothing else but the application setup itself.
As for the backups, I am export containers (lxc export) and storage volumes (zfs send).
Hi,
I ahve the exact same issue. Is it a bug???
https://discuss.linuxcontainers.org/t/lxc-export-error-backup-file-not-found/4953/43