Hi, I’m useing vship for video comparison. After updateing my ram is completly full after I’ve started a video comparison. I tried to use python 3.13 via pyenv and also update vship from the new codeberg repo but it had no effect.
Full, as in “used by programs” or full, as in “used by buffer/cache”?
When any file is read by a program, it’s left in buffer/cache RAM until that space is actually needed by something else (to save disc I/O if that file gets opened again afterwards). Then the OS clears it out when another program needs that RAM.
free -h will give you the necessary info.
2 Likes
Full, as in “used by programs”
buff/cache is staying constant
Welcome to the forum! 
This is not normally anything to worry about if you have a sufficiently sized swap partition or swap file, because this is only cached memory. The kernel will free up the RAM again as soon as it needs more virtual memory for other things.
You can of course manually force the system to free up as much RAM as possible by flushing its buffers to disk and dropping its cache. 
su -c "sync && echo 3 > /proc/sys/vm/drop_caches"
That said, it is of course always possible that the third-party application you’re using would contain a memory leak. In laymen’s terms, this means that the application does not clean up after itself and has marked parts of its memory as dirty — i.e. still in active use — after you’ve quit the application. The kernel then thinks the application is still running, while the process has in fact gone zombie. In that case, a soft reboot will clear that out.
sudo systemctl soft-reboot
This will only reboot the userspace of your system, while the kernel remains in memory. It is much faster than a full reboot because the machine doesn’t have to go through the POST and load the boot loader, which in turn then must load a kernel.
2 Likes
Using zram or zramswap could help.
More swap space gets created dynamically on the fly.
Or (more) swap in general.
But I don’t know the program and how it does the comparison - whether it loads both videos (to what amount) to RAM.
The RAM usage grows more or less linearly with the length of the video / the duration of the comparison. It gets killed by the OS because both RAM and swap reach nearly 100% usage. After quitting the application (either manually or by the OS) the RAM is freed again.
Is there a way to reroll the last update for a while? 
The solution to that would be to increase the available amount of swap. If you’ve got a swap partition, then you can simply add a swap file, and if you only have a swap file and no swap partition, then you can delete and recreate the swap file with a bigger size.
Details can be found on the Arch Wiki…
If you are using btrfs and you have created a snapshot of your root subvolume before updating — as per what snapper or timeshift (can) do — then yes.
And if on top of that, you also have grub-btrfs instead of the regular grub, then you can even just boot straight into the previous version of your system —albeit with a read-only root filesystem — without needing to roll back.
Addendum: In order to better allow us to help you, it would help if you were to supply us with the details of your system. The most common way is via an inxi output, but in this case, what matters is…
- How much RAM is in that machine?
- Do you have a swap partition or a swap file?
- What is the total size of your swap?
- Did you opt for
btrfsas the filesystem, or ratherext4— orxfs, or another Linux-native filesystem? - If
btrfs, did you set up automatic snapshot creation?
CPU: 12-core AMD Ryzen 9 3900X (-MT MCP-) speed/min/max: 2200/2200/4672 MHz
Kernel: 6.18.8-1-MANJARO x86_64 Up: 4h 18m Mem: 6.57/31.28 GiB (21.0%)
Storage: 2.74 TiB (70.9% used) Procs: 551 Shell: Zsh inxi: 3.3.40
ext4 filesystem
The RAM usage climbs very quickly, so I guess I don’t have enough memory/storage for swap to use the program effectively. It also gets very slow once it starts swapping. I’ll take a look at btrfs. Maybe a Docker container with an older Manjaro version could help as well.
Well, yes, swap is going to be much slower, because it has to write to and read from your drive. This is normal when you’re running out of RAM.
Rule #1 for custom compiled applications
- rebuild the recipe after any update
4 Likes