DietPi-Software | Transmission: high RAM usage

[quickplaymobile]

DietPi-Software | Transmission: high RAM usage

[MichaIng]

echo -e '#!/bin/sh\nexec systemctl restart transmission-daemon' > /etc/cron.hourly/restart-transmission
chmod +x /etc/cron.hourly/restart-transmission

[quickplaymobile]

It's related to this high ram usage after finishing downloading. Usually if there are no leachers on the torrent when seeding the hdd goes to sleep. If I don't restart transmission after finishing a download the hdd will stay active, this applies even if I remove or pause the torrent.

Hi!

Don't know if it's related but I've noticed a similar issue with Plex: start streaming something, ram usage goes up, end streaming and ram usage is stuck.

Regards

[quickplaymobile]

Problem still persistent after last update

[MichaIng]

@DesignPixelZ
But the torrents are still in place (ready for seeding). Does RAM usage remain high when you remove the torrents completely from the UI?

Of course, if you disabled seeding, then it wouldn't make sense to keep anything of these torrents in RAM/cache, but that is a different topic. AFAIK there is a way to have finished (downloaded) torrents removed automatically.

[quickplaymobile]

@DesignPixelZ But the torrents are still in place (ready for seeding). Does RAM usage remain high when you remove the torrents completely from the UI?

Yes RAM usage remains high even when removing the torrents completely from the UI.

Of course, if you disabled seeding, then it wouldn't make sense to keep anything of these torrents in RAM/cache, but that is a different topic. AFAIK there is a way to have finished (downloaded) torrents removed automatically.
Seeding wasn't disabled, It didn't had any leaches at the moment.

After restarting transmission and letting it seed for a while everything seems to be normal. The bug seems to occur only after finishing to download a torrent.

[MichaIng]

Okay, as others reported something similar even with recent Transmission versions, we should report this to either Debian or upstream. Would be good to replicate the issue with a public and legal test torrent, so we can write down steps to replicate the issue. Not exactly what I was looking for, but one of those might just do the job: https://whirlpool.net.au/wiki/test_torrents

Would be also good to verify on Debian Trixie/Sid. I'll do so when I find time on a VM.

[quickplaymobile]

Until this gets fixed is there any way to make it reload the service every hour?

I don't have access to reload it manually every time I'm downloading something.

[Joulinar]

I doubt this is something we can fix for our end. However, you could add a crontab entry to restart the service regularly.

[MichaIng]

Doing restarts without explicit knowledge of admin/user is problematic IMO and causes other confusion/problems. I am also not sure whether the raising RAM usage is a problem for everyone, probably many do not recognise it, when their systems have sufficient RAM or do downloads only casually. So let's keep this as possible workaround here, for those, who really have issues with it.

But we should test and in case report to to Debian and/or upstream.

[quickplaymobile]

I have enough RAM to not care about it, but, from what I've seen it also prevents the HDD from sleeping and that may damage it on the long run since is not a SSD.

Thanks for the script! I will probably switch to other torrent client in the future until it gets fixed. And when I have the time I will do a fresh install of dietpi and report if the problem persists.

[MichaIng]

Do you have a swapfile on that external drive? Or is it then really that Transmission somehow keeps the downloaded files from even removed (GUI-wise) torrents open in a way that keeps that drive busy as well?

[quickplaymobile]

Experiencing the same issue with qBittorrent

I will try a clean install.

[quickplaymobile]

I can confirm that I'm having the same issue after a clean install of DietPi.

After finishing downloading.

How it should be... (after reboot).

Edit: I think this may be normal. Downloaded a bigger file and it gets back to 189-ish MB instead of getting stuck at 900+ MB like the image above. So... yeah... I don't know what it was but, it was something.