High CPU usage

[auanasgheps]

Is there a pinned issue for this?

• [X] I have read the pinned issues and could not find my issue

Is there an existing or similar issue/discussion for this?

• [X] I have searched the existing issues
• [X] I have searched the existing discussions

Is there any comment in the documentation for this?

• [X] I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

• [X] I have checked the provider repo for issues
• [X] My issue is NOT related to a provider

Are you using the latest release?

• [X] I am using the latest release

Have you tried using the dev branch latest?

• [ ] I have tried using dev branch

Docker run config used

version: "2"
services:
  transmission:
    image: haugene/transmission-openvpn
    container_name: transmission-vpn
    restart: unless-stopped
    cap_add:
        - NET_ADMIN
    logging:
        driver: json-file
        options:
            max-size: 10m  
    sysctls:
        - net.ipv6.conf.all.disable_ipv6=1
    volumes:
        - /srv/nvme/downloads/:/media
        - /srv/nvme/docker-apps/transmission/config:/config
        - /srv/nvme/docker-apps/transmission/openvpn/:/etc/openvpn/custom
        - /srv/nvme/docker-apps/transmission/config/scripts:/scripts
        - /etc/localtime:/etc/localtime:ro
    environment:
        - PUID=1001
        - PGID=100
        - LOCAL_NETWORK=192.168.0.0/24
        - TZ=Europe/Rome
        - GLOBAL_APPLY_PERMISSIONS=false
        - OPENVPN_PROVIDER=custom
        - OPENVPN_CONFIG=vpnconfig
        - OPENVPN_USERNAME=**None**
        - OPENVPN_PASSWORD=**None**
        - TRANSMISSION_WEB_UI=transmission-web-control
        - TRANSMISSION_DOWNLOAD_DIR="/media/torrent"
        - TRANSMISSION_SCRAPE_PAUSED_TORRENTS_ENABLED=false
        - TRANSMISSION_WATCH_DIR_ENABLED=false
        - TRANSMISSION_DOWNLOAD_QUEUE_SIZE=10
        - TRANSMISSION_PEER_LIMIT_PER_TORRENT=200
        - TRANSMISSION_RATIO_LIMIT=3
        - TRANSMISSION_RATIO_LIMIT_ENABLED=true
        - TRANSMISSION_INCOMPLETE_DIR_ENABLED=true
        - TRANSMISSION_INCOMPLETE_DIR="/media/torrent/_incomplete"
        - TRANSMISSION_SPEED_LIMIT_UP_ENABLED=false
        - TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
        - TRANSMISSION_RPC_USERNAME=superusername
        - TRANSMISSION_RPC_PASSWORD=${RPC_PASSWORD}
    ports:  
        - 9091:9091
    networks:
        default:   
        
networks:
    default:
        external: 
            name: rete
           # Use flag external telling compose that network is already created and should be taken outside, otherwise it will be created on the fly with project prefix  

Current Behavior

This container is using too much CPU compared to what it used to do. Currently there's no torrent being actively downloaded or uploaded, so I would expect a very low CPU consumption. To be clear I have few torrents in seeding state, but network activity is 0 because nobody is pulling them. Here's the situation:

Expected Behavior

Low CPU usage when there are no torrents actively transferred, as it used to be in the past. Around 5% or lower

How have you tried to solve the problem?

• Checked VPN connection is fine
• Using the latest version
• Nothing strange in transmission.log

Log output

Every hour it prints this, I think it's normal:

2023-12-30 18:05:58 TLS: soft reset sec=3600/3600 bytes=316893946/-1 pkts=2499308/0

2023-12-30 18:05:58 VERIFY OK: depth=1, CN=TG-VPN-CA

2023-12-30 18:05:58 VERIFY KU OK

2023-12-30 18:05:58 Validating certificate extended key usage

2023-12-30 18:05:58 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

2023-12-30 18:05:58 VERIFY EKU OK

2023-12-30 18:05:58 VERIFY OK: depth=0, CN=server

2023-12-30 18:05:58 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1582', remote='link-mtu 1569'

2023-12-30 18:05:58 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'

2023-12-30 18:05:58 WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'

2023-12-30 18:05:58 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'

2023-12-30 18:05:58 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

2023-12-30 18:05:58 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

2023-12-30 18:05:58 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256

HW/SW Environment

- OS: Debian 11
- Docker: 24.0.7

Anything else?

An update: The CPU usage is not constant. The day after I opened this issue it was about 7-8%, with the same conditions (no torrent actively being downloaded or uploaded). I would like to understand what Transmission is doing, but the logs don't say much.

[auanasgheps]

Glances shows that most of the activity is done by Transmission itself and not OpenVPN:

But there's nothing really being done. Maybe this issue is unrelated to the container and I should ask to the Transmission project, but I wanted to get your feedback first.

[ilike2burnthing]

Do you have the same problem on the dev branch?

[auanasgheps]

Just tried with the dev branch, and yes:

[SpiralBrad]

Having a similar problem, also only as of the past week or so; also seeing high disk activity when this happens.

[auanasgheps]

I'm guessing this is not a problem specific to this container but to Transmission, but I'm waiting for a confirmation.

[ilike2burnthing]

Provide the response to uname -a on your host device.

Have you tried a normal Transmission container with a few Ubuntu iso torrents, see if you get the same issue?

Have you tried earlier images? https://hub.docker.com/r/haugene/transmission-openvpn/tags (as well as the earlier version number images, also try the focal and kinetic images)

[auanasgheps]

I still haven't tried a normal Transmission container, but I would like to understate that this behaviour is seen when there is NO torrent activity. I would not complain about 15% CPU load when downloading (actually is pretty good).

BTW this is the output Linux nas 6.1.0-0.deb11.13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1~bpo11+1 (2023-10-08) x86_64 GNU/Linux (It's OpenMediaVault 6)

[ilike2burnthing]

Oh sorry, I meant a few Ubuntu iso torrents downloaded, seeding but idle, to semi-replicate your current container.

[auanasgheps]

I haven't done anything, but CPU usage is now at about 5%. I'll keep you posted when I can do more testing

[SpiralBrad]

My container is once again behaving as well. Very strange.

[ilike2burnthing]

It was just having a little hissy fit, it's over it now ;)

[auanasgheps]

I'll monitor the usage for a couple of days. If nothing changes, I'll close this.

[auanasgheps]

This can be closed. I've monitored resources consumption, and the issue did not show up again. I hope it's the same for you!