High CPU usage , low bandwidth

[chmol]

Describe the problem

Hi, since a few day I've been experiencing really high cpu load (1 core at 100% for transmission) when downloading : the speed reach the maximum my connection can handle (~200mbps) then drop to 50mbps whereas the load stays the same.

Openvpn usage is low.

systemd

[Unit]
Description=haugene/transmission-openvpn docker container
After=docker.service
Requires=docker.service

[Service]
User=bittorrent
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill transmission-openvpn
ExecStartPre=-/usr/bin/docker rm transmission-openvpn
ExecStartPre=/usr/bin/docker pull haugene/transmission-openvpn
ExecStart=/usr/bin/docker run --sysctl  net.ipv6.conf.all.disable_ipv6=0 \
       --name transmission-openvpn \
       --cap-add=NET_ADMIN -d \
       -e CREATE_TUN_DEVICE=true \
       -v /home/bittorrent/data:/data \
       -v /mnt/pool/media:/mnt/pool/media \
       -v /srv/pool/media:/srv/pool/media \
       -v /mnt/pool/downloads/series:/mnt/pool/downloads/series \
       -v /srv/pool/downloads/series:/srv/pool/downloads/series \
       -e "OPENVPN_PROVIDER=MULLVAD" \
       -e "OPENVPN_CONFIG=nl_all" \
       -e "OPENVPN_USERNAME=user" \
       -e "OPENVPN_PASSWORD=username" \
       -e "LOCAL_NETWORK=192.168.2.0/24" \
       -e "TRANSMISSION_CACHE_SIZE_MB=1400" \
       -e "TRANSMISSION_DOWNLOAD_DIR=/mnt/pool/downloads/" \
       -e "TRANSMISSION_DHT_ENABLED=false" \
       -e "TRANSMISSION_ENCRYPTION=2" \
       -e "TRANSMISSION_INCOMPLETE_DIR_ENABLED=false" \
       -e "TRANSMISSION_PEER_PORT=19279" \
       -e "TRANSMISSION_PEX_ENABLED=false" \
       -e "TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true" \
       -e "TRANSMISSION_RPC_USERNAME=blabla" \
       -e "TRANSMISSION_RPC_PASSWORD=dldldldllddl"\
       -e "TRANSMISSION_WATCH_DIR=/mnt/pool/downloads/~watch" \
       --dns 192.168.1.1 \
       -p 9091:9091 \
       -e "OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60" \
       haugene/transmission-openvpn

[Install] WantedBy=multi-user.target

Logs

> Fri Nov 20 11:26:08 2020 VERIFY KU OK
> Fri Nov 20 11:26:08 2020 Validating certificate extended key usage
> Fri Nov 20 11:26:08 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
> Fri Nov 20 11:26:08 2020 VERIFY EKU OK
> Fri Nov 20 11:26:08 2020 VERIFY OK: depth=0, C=SE, ST=Gotaland, O=Amagicom AB, OU=Mullvad, CN=nl-ams-001.mullvad.net, emailAddress=security@mullvad.net
> Fri Nov 20 11:26:08 2020 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1558'
> Fri Nov 20 11:26:08 2020 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
> Fri Nov 20 11:26:08 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
> Fri Nov 20 11:26:08 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
> Fri Nov 20 11:26:08 2020 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 4096 bit RSA
> 

Host system:

Debian GNU/Linux 10 (buster), whitebox nas x64 arch, Docker version 19.03.13, build 4484c46d9d

[chmol]

How can I downgrade transmission? Should the container be rebuild?

[chmol]

Thanks for the warning will have to backup that first then.

I'm not sure how to use the information you just provided, this is a revised docker build against the current one?

[YujiShen]

@chmol did you upgrade container recently to 3.x version (image version, not transmission)?

[chmol]

Yes, the systemd unit pull a new container when it start.

[chmol]

fixed - somehow

I tested with the recent container. Still high usage.

Looking for something less traditional with my setup I looked at the docker args. I had transmission_cache_size_mb set to 1500 , reducing to 100 reduce the cpu load. But it is still too high: transmission on an older less performant laptop has a lower load.

I assume that this problem is not related to this docker image but transmission itself.

Could others try to increase their cache and see if the error is reproduced?

tldr: reduce transmission_cache_size_mb

[PieterVreysen]

I think I have the same problem. First thought it was my VPN or internet provider shaping my traffic. Changing transmission_cache_size_mb doesn't seem to help much.

[superkrups20056]

Hi, I have a synology NAS and the same thing is happening to me after updating the container from 2.14 to 3.2. Quick question, was 2.14 using Transmission 2.9? because if it was then this is the solution for me too. 3.2 is taking DAYS to parse old torrent files. and slows to a snail's crawl when downloading.

EDIT: It seems that transmission 2.14 was using 3.0 as well and I was not running into this problem then. This is a fresh container build.

[superkrups20056]

System monitor constantly has this:

[chmol]

@PieterVreysen @superkrups20056 what's the spec of your devices?

I assume that my i5 is more capable than a arm.

I'm not familiar with docker (other than running a cli) would it be possible to create an image without the vpn and test if the problem is:

• from the interaction openvpn - transmission ( unlikely)
• from this transmission version - saw this searching around , but this image share the same version than my laptop under arch (3.00 bb6b5a062e). My laptop doesn't have that problem
• from transmission as packaged on alpinelinux which is pulled by docker.

[superkrups20056]

@PieterVreysen @superkrups20056 what's the spec of your devices?

I assume that my i5 is more capable than a arm.

I'm not familiar with docker (other than running a cli) would it be possible to create an image without the vpn and test if the problem is:

• from the interaction openvpn - transmission ( unlikely)
• from this transmission version - saw this searching around , but this image share the same version than my laptop under arch (3.00 bb6b5a062e). My laptop doesn't have that problem
• from transmission as packaged on alpinelinux which is pulled by docker.

@chmol I'm on a DS218+. When nothing is downloading the CPU is acceptable. When a downloaded file starts, it goes up to 100% like you see above and transmission takes 20 seconds to load when you go to the page. This never happened on 2.14. Also checking takes forever as well, taking days to parse old files.

I don't think its the transmission version because 2.14 was on version 3.00 on Transmission and was fine. I wonder if it is the new VPN infrastructure? Download and upload speeds are a lot faster, I've noticed, albeit destroying my CPU!

[PieterVreysen]

@chmol I'm on a DS918+ (INTEL Celeron J3455, so no ARM)

Same issues as @superkrups20056 described, 2.14 worked fine.

[chmol]

I worded my sentence wrongly sorry, I was asking if they were low power cpu (I somehow remembered that synology ran on arm)

@superkrups20056 are you referring to your vpn provider infrastructure? If they upgraded it make sense that you have faster speed at the cost of greater cpu load. I was already maxing out my connection before but the cpu now struggle.

I guess one of us will have to play around in docker to isolate the cause. I'll see if I can manage that this weekend.

[superkrups20056]

@chmol Yes, I was referring to PIA's next gen servers.

[susman]

It's actually quite easy to isolate the problem: 1) create a container that connects to PIA ( openvpn/wireguard - does not matter ), possible images: https://hub.docker.com/r/itsdaspecialk/pia-openvpn https://hub.docker.com/r/thrnz/docker-wireguard-pia 2) use any transmission image, I used that one: https://hub.docker.com/r/linuxserver/transmission 3) combine it all in a docker-compose file:

version: '3.8'
services:
  piawg:
    container_name: piawg
    image: thrnz/docker-wireguard-pia:arm64v8
    volumes:
      - pia:/pia
      - pia-shared:/pia-shared
    restart: unless-stopped
    ports:
      - 9091:9091
    cap_add:
      - NET_ADMIN
    environment:
      - LOC=czech
      - USER=pXXXXXXXXX
      - PASS=XXXXXXXXX
      - PORT_FORWARDING=1
      - LOCAL_NETWORK=192.168.1.0/24
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.default.disable_ipv6=1
      - net.ipv6.conf.all.disable_ipv6=1
      - net.ipv6.conf.lo.disable_ipv6=1
    healthcheck:
      test: ping -c 1 www.google.com || exit 1
      interval: 5s
      timeout: 2s
      retries: 10

  transmission:
    #    image: linuxserver/transmission:arm64v8-latest
    image: linuxserver/transmission:arm64v8-2.94-r3-ls53
    container_name: transmission
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Prague
      - TRANSMISSION_WEB_HOME=/transmission-web-control
      - USER=user
      - PASS=pass
    volumes:
      - <path to config>:/config
      - <path to downloads>:/downloads
      - <path to watch>:/watch
      - pia-shared:/pia-shared:ro
    restart: unless-stopped
    network_mode: "service:piawg"
    healthcheck:
      test: curl -I -m 1 localhost:9091 || exit 1
      interval: 5s
      timeout: 2s
      retries: 10
    depends_on:
      piawg:
        condition: service_healthy

volumes:
  pia:
  pia-shared:

Now we can switch transmission images without affecting the VPN: when I use 'arm64v8-2.94-r3-ls53' transmission image - I get my 350Mb/s. When I switch to 'latest' - I observe the mentioned above behavior.

[chmol]

Thanks, that's really helpfull but is it a transmission issue under alpine? Or a docker issue as packaged by linuxserver ?

I've never used docker before other than this image, i'm out of my depth.

[susman]

IMO the issue is transmission ( even if it's kernel_task, transmission is the one submitting the task ). Either it's 2.x vs 3.x or 3.x vs 'latest' ( whatever the version is right now ), but I never tested any other than 'latest' 3.x versions.

[susman]

yep, it's transmission: https://github.com/transmission/transmission/issues/1314

[cmunk]

Is there an easy fix for now? Can I revert to a previous version of this docker image?

[ilike2burnthing]

@cmunk yes, replace latest in haugene/transmission-openvpn:latest with your desired version number, e.g. 3.0 or 2.14 - https://hub.docker.com/r/haugene/transmission-openvpn/tags

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[pkishino]

looking at transmission to fix this at source then we can pull it in.. @haugene other option would be to downgrade transmission

[bbender716]

For what it's worth, I had to roll-back from latest for transmission to not stall out at 100% cpu. I'm on 3.0 tag for the foreseeable future and using a custom ovpn Windscribe config since rolling back loses the benefit of the new method of handling configs.

I also clearly advocate for rolling back the transmission version until the issue referenced above is resolved at the source.

[haugene]

Yeah. I'm thinking that a rollback of Transmission is warranted. I'm also seeing this in relation to #1726 as a larger question on our release strategy as well. That is provoked by us bumping to latest alpine in order to get OpenVPN 2.5. Updating to be on the latest versions of stuff is good and well - but I think we might want to take a stand and say that we value stability over bleeding edge. We will upgrade regularly, but roll back if we meet resistance and try again 6 months later. Dependency hell is no fun :)

I'm also considering going back to ubuntu as a base image. That is where this project started and I think it will contribute to more stable operation in the years to come as well. Stay on the LTS'es and keep it simple. I know alpine is low footprint and that's great, but it's a matter some tens of megabyte (have to verify this) and I think that just has to be accepted.

[chmol]

I would definitively chose stability over a few mb.

Good luck with the dependency hell.