DietPi-Software | Transmission: RAM usage raises unlimited in Stretch repo version

[GulyFMG]

ADMIN EDIT

Workaround: #2413 (comment)

---

Required Information:

• DietPi version | #!/bin/bash
  G_DIETPI_VERSION_CORE=6
  G_DIETPI_VERSION_SUB=19
  G_DIETPI_VERSION_RC=7
  G_GITBRANCH=master
  G_GITOWNER=Fourdee

• Distro version | 9.6

• Kernel version | Linux blacksun 4.14.80-v7+ #1161 SMP Mon Nov 12 18:51:43 GMT 2018 armv7l GNU/Linux

• SBC device | RPi 3 Model B+ (armv7l)

• Power supply used 5V

• SDcard used | SanDisk 16Gb

Additional Information (if applicable):

• Software title | Transmission

Steps to reproduce:

Just download a torrent with transmission.

At boot memory print is low when it is downloading a torrent is growing as expected but at the end the memory get "locked" after a couple of hour i need to reboot transmission to reduce memory consumption.

Expected behaviour:

after download transmission should release memory

Actual behaviour:

after download transmission doesn't release memory

Extra details:

transmission/transmission#313 (comment)
i did some dig around and it looks like "The problem is solved in Debian since 2.94 packaging [1] by applying the proposed workaround. But in general it is not yet solved. I continue investigating this further."

Best Regards

[MichaIng]

@GulyFMG
Thanks for your report.

We install Transmission from Debian repo indeed, where the fix has not yet been applied.

Only thing we can do is built a custom package each architectures and place it on our server. But requires some work and much testing and could mess with the Debian package, it's files, e.g. systemd unit and such 🤔.

Would be great if we could push the fix to be applied in Debian Stretch. Perhaps a comment to the closed bug report to ask for a backport to Stretch will do: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865624
But for sure this would be no short term fix 😉.

[GulyFMG]

How about a simple script to restart the service after x % of memory usage?

[MichaIng]

@GulyFMG
Theoretically yes, but I guess this would break any running downloads. Not great, if one downloads something large and then needs to start from the beginning? Even if the download could be resumed (instead of restarted), a random service restart while you are navigating the web UI also is not ideal 🤔.

[GulyFMG]

True , i did some inicial testing wth qbitorrent and deluge and both suit my needs... so maybe im gonna drop transmission until its patch. Thank you for the input.

[1265578519]

确实存在这个问题，Linux工作机制应该就是把内存用尽，软件层没有办法解决

[MichaIng]

@1265578519
Please use an international char set + language, otherwise we can't read your input 🙂.

[MichaIng]

I reopen the topic, to not forget following the issue externally and in case push a backport of the fix to Debian Stretch.

[MichaIng]

Ref: https://dietpi.com/phpbb/viewtopic.php?t=6034

[GulyFMG]

Hey guys,
i did 2 things to mitigate the issue:
first i changed the value to "cache-size-mb": 32
second create an alias to restart transmission:
Edit file nano ./root/.bashrc at the end of the file add:
alias rt='dietpi-services restart transmission-daemon'

Restart bashrc
exec bash

and for now its pretty stable one thing that was making the problem worse was jackett but since they release the non mono version, my system has been pretty stable.

[MichaIng]

@GulyFMG
Thanks for sharing your solution.

Little note:

• If one logs in with a custom user, /root/.bashrc does not work, apply the alias failsafe for the current user: echo "alias rt='dietpi-services restart transmission-daemon'" >> ~/.bashrc

[GulyFMG]

@MichaIng
Thanks for the tip.

[nicoolaro]

my ./root/.bashrc is empty, should i still add alias rt='dietpi-services restart transmission-daemon'
in that empty file.
Logged as root.
edit: actually Directory ./root does not exist .

Edit 2: finally got it, .bashrc is present in root, i used @MichaIng your script and it added line to the file.

Sorry total newbie

[MichaIng]

@nicoolaro
Note that the "cache-size-mb": 32 setting is the one that limits transmission RAM usage. @GulyFMG what does actually happen it this limit exceeds, does the service hang, so you need to restart?

The line just adds the rt command which can then be used to quickly restart transmission, instead of the usually required dietpi-services restart transmission-daemon or systemctl restart transmission-daemon.

However we need to find a solution from this issue so that Transmission does not use this much RAM.

[GulyFMG]

hey,
since I changed the cache transmission only uses 10% of RAM so approximately double the cache and stays there, it's doesn't free the ram but at least it doesn't go up either.

the thing that was eating the ram was mono related apps like sonarr, radarr and Jackett, being the biggest offender Jackett, and it would crash the system.

I'm on the phone so can't send much more info.

[MichaIng]

@GulyFMG
Ah yeah of course it's the cache size, so should not crash if exceeded, but in case makes Transmission behave a bid slower.

We already have a system inside dietpi-software to set reasonable cache sizes based on available memory, however not applied to all software titles. Will see if we can apply it for Transmission so that it consumes at max 10% of available RAM, which would be min 20M on 256M RPi models (not 25/26, because of GPU memory share).

However 200M memory consumption for a torrent downloader (that states to be lightweight) without any runtime system is simply a hint for a memory leak that needs to be fixed.

[MichaIng]

Puhh, source build is not too trivial (official instruction do not work OOTB, "no supported crypto library found", configure file missing that docs state, pre-reqs take > 600M disk size, several X11 packages included somehow due to dependency tail... Nothing I am keen to ship to end users and requires much testing on all hardware models...

Finally the only thing that I could imagine is that we host custom binaries for current and place them on top of the APT install (so user + systemd unit etc setup does not need to be done manually). But I have no ARMv6 or ARMv8 machine here. Also a bid out of scope for v6.25 at least.

Moved to outstanding milestone for now. Will have another look after v6.25 release. However if someone wants to compile binaries, I am happy to host them on dietpi.com and ship with our Transmission install for the related architecture.

[MichaIng]

I mark this issue as closed now since we don't ship any Stretch image anymore and with Buster the initial issue has been resolved. There seem to be still cases where Transmission does not release memory/cache as expected, but we should track those in a new issue, in case.

[igorkulman]

Is this supposed to be solved? Because I am experiencing the exact same problem on DietPi 6.34.3

[Joulinar]

@igorkulman
Are you running Buster or Stretch?

[igorkulman]

@igorkulman
Are you running Buster or Stretch?

Doing cat /etc/os-release says VERSION_CODENAME=buster. I installed DietPi in November 2020 I think.

[MichaIng]

Yes as can be seen in above discussion, while the major issue on Stretch has been solved with the version shipped with Buster, Transmissions still seems to have a memory leak issues. I can't find it, but one user "solved" it by regularly restarting the service. Since we have thousands of Transmission users, I don't thing it is a general issue, especially memory usage does not raise to 100%, but at least it does not release memory to initial state after torrents have been removed. @igorkulman can you go a bit more into detail, how much memory does Transmission use at startup (without active torrents), how much while having a certain amount of active torrents, and how much after those did finish/have been removed? htop could be used to track it.

[igorkulman]

Yes as can be seen in above discussion, while the major issue on Stretch has been solved with the version shipped with Buster, Transmissions still seems to have a memory leak issues. I can't find it, but one user "solved" it by regularly restarting the service. Since we have thousands of Transmission users, I don't thing it is a general issue, especially memory usage does not raise to 100%, but at least it does not release memory to initial state after torrents have been removed. @igorkulman can you go a bit more into detail, how much memory does Transmission use at startup (without active torrents), how much while having a certain amount of active torrents, and how much after those did finish/have been removed? htop could be used to track it.

When transmission-deamon is starts it takes up 1% memory on my RPi 2. I can navigate to the Web UI, still 1%.

When I start a torrent the memory usage starts to climb slowly up to 27.4%, never exceeding it (Kodi for comparison is a stable 26%).

When the download finishes, the memory stays at 27.4% never coming down, no matter what I do. Starting another download does not increase it further. My total memory usage at that point is always around 80%.

Only restarting the transmission-deamon bring it back to 1%.

[MichaIng]

Okay, that matches other observations. I think most users do not recognise or mind, when running that daemon 24/7 with always active torrents anyway, but I agree that a good program should release memory when changing from active to idle state, in this case memory that is used for downloading/seeding active torrents, after those torrents have been removed.

Let's see if the new v3 works better. It is quite easy to install manually from Bullseye repository:

apt update
cd /tmp
curl -O -O -O https://deb.debian.org/debian/pool/main/{libe/libevent/libevent-2.1-7_2.1.12-stable-1_amd64,t/transmission/transmission-daemon_3.00-1_amd64,t/transmission/transmission-common_3.00-1_all}.deb
apt install ./*.deb

[Dr0bac]

You can lower cache size mb in transmission config file and then memory will not rise to that level.. on my end transmission also doesn't release memory after torrent is finished/deleted..

[igorkulman]

Okay, that matches other observations. I think most users do not recognise or mind, when running that daemon 24/7 with always active torrents anyway, but I agree that a good program should release memory when changing from active to idle state, in this case memory that is used for downloading/seeding active torrents, after those torrents have been removed.

Let's see if the new v3 works better. It is quite easy to install manually from Bullseye repository:

apt update
cd /tmp
curl -O -O -O https://deb.debian.org/debian/pool/main/{libe/libevent/libevent-2.1-7_2.1.12-stable-1_amd64,t/transmission/transmission-daemon_3.00-1_amd64,t/transmission/transmission-common_3.00-1_all}.deb
apt install ./*.deb

Actually it is not that easy

root@DietPi:/tmp# apt install ./*.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libevent-2.1-7:amd64' instead of './libevent-2.1-7_2.1.12-stable-1_amd64.deb'
Note, selecting 'transmission-common' instead of './transmission-common_3.00-1_all.deb'
Note, selecting 'transmission-daemon:amd64' instead of './transmission-daemon_3.00-1_amd64.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libevent-2.1-7:amd64 : Depends: libc6:amd64 (>= 2.25) but it is not installable
 transmission-daemon:amd64 : Depends: transmission-common:amd64 (= 3.00-1) but it is not installable
                             Depends: libc6:amd64 (>= 2.17) but it is not installable
                             Depends: libcurl4:amd64 (>= 7.18.0) but it is not installable
                             Depends: libminiupnpc17:amd64 (>= 1.9.20140610) but it is not installable
                             Depends: libnatpmp1:amd64 (>= 20150609) but it is not installable
                             Depends: libssl1.1:amd64 (>= 1.1.0) but it is not installable
                             Depends: libsystemd0:amd64 but it is not installable
                             Depends: zlib1g:amd64 (>= 1:1.1.4) but it is not installable
E: Unable to correct problems, you have held broken packages.

Anyway, I think I will stick with systemctl restart transmission-deamon, maybe put it into cron or as part of one of my scheduded script that needs a lot of memory.

Edit: Just noticed, your command downloads amd64, I need to change it to armhf.

[Joulinar]

can you post uname -a

[igorkulman]

can you post uname -a

Linux DietPi 5.4.72-v7+ #1356 SMP Thu Oct 22 13:56:54 BST 2020 armv7l GNU/Linux

[Joulinar]

I guess you would need to replace all amd64.deb with armhf.deb

and don't forget to delete amd64.deb files on /tmp

[igorkulman]

Using Transmission 3.00 installed manually there is not much of a change, just that the memory usage is a bit lower. Stays az 22% after download finishes, also never drops down back.

[Joulinar]

did you tried to lower cache size as indicated above #2413 (comment)

[MichaIng]

Ah lol sorry for linking the wrong architecture, copy paste from x86_64 VM console 😄.

[quickplaymobile]

Having same problem on

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

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

Transmission gets stuck and eats about 1.5 - 1.6 GB of RAM. Problem is that it keeps my external HDD active and it may damage it.

[Joulinar]

the topic is more than 3 years old and has been closed. Pls open a new issue and fill the required information. thx for understanding.

[quickplaymobile]

the topic is more than 3 years old and has been closed. Pls open a new issue and fill the required information. thx for understanding.

I don't see a reason, It's the exact issue. on the latest version of dietpi. Something may've break along the way.

[MichaIng]

No it is an entirely different issue, even sounds like expected or something which can be solved by changing the configuration. The issue here is about a bug in the Transmission version shipped with Debian stretch, while you run the 2 versions newer Debian Bullseye with much newer Transmission, which is not affected by this bug 😉.

EDIT: Although, the newer comments here seem to indicate that it still has a memory leak in some situations (but a different one). However, OP issue is long obsolete, so a new issue makes sense in any case.