Transmission-daemon效率低下及remote命令失效问题咨询

1. Why is Transmission-daemon Underperforming Compared to BitTornado? #

Your setup with 11 servers, 40G test files, and CentOS 6 gives us a clear context—let’s break down the key reasons for this performance gap:

Root Causes #

• Ancient Transmission Version: Transmission 2.13 (11501) is a 2011-era build. Over the past decade, later releases (3.x and beyond) have rolled out massive optimizations for CPU efficiency, network IO handling, and peer management. BitTornado, even as a Python-based client, might be better aligned with your workload in this older ecosystem, while Transmission’s 2.13 carries unaddressed bottlenecks (like single-threaded task handling that hogs CPU without utilizing full available bandwidth).
• CentOS 6 Limitations: CentOS 6 runs a 2.6.x kernel, which lacks modern network features like advanced TCP congestion control algorithms (BBR isn’t supported here), improved file system caching, and smarter thread scheduling. SCP’s simpler transfer logic (no peer discovery, tracker communication, or piece validation overhead) lets it leverage bandwidth more easily than a BT client constrained by an outdated kernel.
• Conservative Default Configuration: Transmission 2.13’s out-of-the-box settings are tuned for low-resource environments. Small cache sizes, low peer limits, or disabled DHT/LPD can throttle bandwidth, while inefficient peer connection handling might cause unnecessary CPU spikes.

Fixes to Try #

• Upgrade Transmission (or Your OS):
  • CentOS 6 is end-of-life, so upgrading to CentOS 7+ (or a modern distro like Rocky Linux) is the long-term solution—it supports newer Transmission versions and kernel improvements that directly boost performance.
  • If you must stay on CentOS 6, compile a newer Transmission version from source (note: you’ll need to resolve dependencies like updated libtorrent).
• Tweak Transmission Settings:
  • Edit your settings.json file (typically located at /var/lib/transmission/.config/transmission-daemon/):
    • Increase cache-size-mb to 64 or 128 (reduces disk IO overhead)
    • Set peer-limit-per-torrent to 100+ (adjust based on your server’s capacity)
    • Enable bt-enable-dht and bt-enable-lpd for better peer discovery
    • Set speed-limit-up and speed-limit-down to 0 (remove artificial bandwidth caps)
  • Restart the daemon with service transmission-daemon restart after making changes.
• Optimize Kernel Network Parameters:
  • Edit /etc/sysctl.conf to adjust TCP settings:

    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    net.ipv4.tcp_window_scaling = 1
    net.ipv4.tcp_congestion_control = htcp
    

  • Apply changes with sysctl -p.

2. Why Isn’t transmission-remote --remove-and-delete Working? #

The issue here almost certainly stems from incorrect syntax or limitations in the old 2.13 client:

Root Causes #

• Incorrect Torrent Identifier: The -t flag expects a torrent numeric ID (from the list view) or info hash, not the filename (attr.dat). Transmission 2.13 doesn’t support targeting torrents by filename with the -t parameter.
• Potential Permission or Version Bugs: While 2.13 does include --remove-and-delete, older versions sometimes have bugs with combined flags, or the transmission-daemon user may lack permissions to delete the underlying files.

Fixes to Try #

• Use the Correct Torrent ID:
  1. List all torrents to get their numeric IDs:

     transmission-remote $host -l
     

  2. Locate the ID in the first column next to attr.dat, then run:

     transmission-remote $host -t [TORRENT_ID] --remove-and-delete
     

• Verify Permissions:
  • Ensure the transmission-daemon user (usually transmission) has write/delete permissions for the download directory and the torrent file itself.
• Fallback if Needed:
  • If --remove-and-delete still fails, split the operation: first remove the torrent from Transmission with transmission-remote $host -t [TORRENT_ID] --remove, then manually delete the files via SSH.

内容的提问来源于stack exchange，提问作者jacky