DietPi-Software | Transmission: high RAM usage

[quickplaymobile]

Creating a bug report/issue

• [ Yes ] I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version

G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=25
G_DIETPI_VERSION_RC=1
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN

bullseye 0

• Kernel version | uname -a

Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)

RPi 4 Model B (aarch64)

• Power supply used | (EG: 5V 1A RAVpower)

Official RPi 4 charger (Raspberry Pi 15W USB-C Power Supply)

• SD card used | (EG: SanDisk ultra)

---

Additional Information (if applicable)

• Software title | (EG: Nextcloud)

44 Transmission: BitTorrent server with web interface (C)

• Was the software title installed freshly or updated/migrated?

Not sure, remember seeing an update 2 months ago.

• Can this issue be replicated on a fresh installation of DietPi?

---

• Bug report ID | echo $G_HW_UUID

---

Steps to reproduce

1. Download any torrent.
2. Seed the torrent for a couple of hours.

Expected behaviour

1. Torrent starts downloading.
2. Ram usage goes UP.
3. Torrent finishes downloading.
4. Ram usage goes back to normal range.

Actual behaviour

1. Torrent starts downloading.
2. Ram usage goes UP.
3. Torrent finishes downloading.
4. Ram usage gets stuck at 1.5 - 1.6 GB usage.

Extra details

I don't have any logs or anything else I can say about it. More than an anomaly in ram usage and the external HDD remaining active. I also found out that even if I delete the torrent from transmission the ram usage get stuck and HDD stays active.

[ghost]

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.

[MichaIng]

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

[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]

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.

[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.