search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.88k stars 497 forks source link

DietPi-Software | Transmission: high RAM usage #6849

Open quickplaymobile opened 10 months ago

quickplaymobile commented 10 months ago

Creating a bug report/issue

Required Information

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

bullseye 0

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

RPi 4 Model B (aarch64)

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

Additional Information (if applicable)

44 Transmission: BitTorrent server with web interface (C)

Not sure, remember seeing an update 2 months ago.

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 commented 9 months ago

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 commented 9 months ago

Problem still persistent after last update Untitled-1

MichaIng commented 9 months ago

@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 commented 9 months ago

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

Untitled-1

MichaIng commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago 
echo -e '#!/bin/sh\nexec systemctl restart transmission-daemon' > /etc/cron.hourly/restart-transmission
chmod +x /etc/cron.hourly/restart-transmission
Joulinar commented 9 months ago

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

MichaIng commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 8 months ago

Experiencing the same issue with qBittorrent Screenshot 2024-02-23 173913

I will try a clean install.

quickplaymobile commented 8 months ago

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

After finishing downloading. after download

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

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.