Transmission Daemon 2.22 causing high CPU load

[ross105]

Hello!
Found one issue - when I add torrent with 8 mb parts (last one was 862 x 8 MB) I get slow download speed 300-350 Kb/s and almost 100% CPU load. If I stop this torrent I get full speed on others torrents and 0 CPU load.

How to fix it?

[rb07]

Have you tried changing the "Maximum memory cache size"?

One reference is here: Re: Any suggestions on cache-size-mb?

You can see what the daemon is using with something like:

Code: Select all

$ transmission-remote -si
VERSION
  Daemon version: 2.22 (12099)
  RPC version: 11
  RPC minimum version: 1

CONFIG
  Configuration directory: /####/transmission/config
  Download directory: /####/transmission/downloads
  Download directory free space: 27.32 GiB
  Listenport: ####
  Portforwarding enabled: No
  Distributed hash table enabled: Yes
  Local peer discovery enabled: No
  Peer exchange allowed: No
  Encryption: preferred
  Maximum memory cache size: 16.00 MiB
...

and change it on the fly with:

Code: Select all

transmission-remote -e 8

for the recommended 8 MiB, but the value depends on your WAN speed (I'm using 16).

[ross105]

Increased cahe size to 20 Mb. No luck - 90% CPU usage, and low speed on all torrents...

[rb07]

Perhaps its time to open a bug report.

There's a similar thread on this forum, where the main point is that going from version 2.13 to 2.22 results in high CPU load and that it affects throughput. Your report gives another point (the piece size), which could be important.

[Jordan]

What OS are you on?

You might want to try running transmission in "perf" to see where it's spending all of those cycles. From the information here, my best guess is that it's probably verifying piece checksums, which is normal and will stop after all the pieces have been checked.

[gunzip]

i'm seeing this in the latest nightlies also, but only for very large multi-file torrents (> 600 files). these are very rare in my experience. i did a profile when hitting 100% CPU load and something called countArray is hogging all resources:

Code: Select all

CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples  %        linenr info                 symbol name
63136    95.3543  bitfield.c:49               countArray
474       0.7159  bitfield.c:61               countRange
398       0.6011  (no location information)   __udivdi3
299       0.4516  completion.c:137            tr_cpSizeWhenDone
239       0.3610  peer-mgr.c:1046             pieceListLookup
237       0.3579  torrent.c:2316              tr_torGetPieceBlockRange
194       0.2930  bencode.c:1367              jsonStringFunc
109       0.1646  completion.c:198            tr_cpMissingBlocksInPiece
106       0.1601  peer-mgr.c:2823             rechokeDownloads
95        0.1435  bencode.c:1042              bencWalk

Linux Debian, transmission-daemon 2.30b4 (12426)

[ross105]

In my case it is single file 8 Gb torrent with 8 Mb parts.
This problem exists on all 8 Mb parted torrent files.

For example
8 Mb parted file turned on:

Turned off:


In utorrent on windows machine that file is downloading ok, on full bandwidth and not causing high CPU usage.
On ubuntu High CPU usage, Slow speed on all other torrents, almost not accessible server.

P.S.
System Specs:
Operating system: Ubuntu Linux 10.04.2
Kernel and CPU: Linux 2.6.32-31-generic on x86_64
Processor information: Intel(R) Atom(TM) CPU D425 @ 1.80GHz, 2 cores
Real memory: 1.95 GB total, 271.64 MB used
Virtual memory: 5.72 GB total, 0 bytes used
Local disk space: 2.68 TB total, 1.03 TB used
Transmission daemon: 2.22

[Jordan]

Thanks for the great profile. Nearly all of those calls to countArray() will disappear when 2.30 goes out the door -- they're in assertions that are disabled in the stable releases.

i'm seeing this in the latest nightlies also, but only for very large multi-file torrents (> 600 files). these are very rare in my experience. i did a profile when hitting 100% CPU load and something called countArray is hogging all resources:

Code: Select all

CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples  %        linenr info                 symbol name
63136    95.3543  bitfield.c:49               countArray
474       0.7159  bitfield.c:61               countRange
398       0.6011  (no location information)   __udivdi3
299       0.4516  completion.c:137            tr_cpSizeWhenDone
239       0.3610  peer-mgr.c:1046             pieceListLookup
237       0.3579  torrent.c:2316              tr_torGetPieceBlockRange
194       0.2930  bencode.c:1367              jsonStringFunc
109       0.1646  completion.c:198            tr_cpMissingBlocksInPiece
106       0.1601  peer-mgr.c:2823             rechokeDownloads
95        0.1435  bencode.c:1042              bencWalk

Linux Debian, transmission-daemon 2.30b4 (12426)

[ross105]

Strange... Came home to check this thread.
Transmission was downloading that 8 Mb. parted file on low speed... Stopped and resumed that torrent and bang - 1.5 Mb/sec...
Ill check more 8 mb. torrents to see stats.

BTW - how to use "perf" with transmission to build profile mentioned above?

[gunzip]

Nearly all of those calls to countArray() will disappear when 2.30 goes out the door -- they're in assertions that are disabled in the stable releases.

OK that's interesting and important to know. But after 2.30 stable is released, will future 2.30+ nightlies re-enable these asserts? This could have a major effect on how one interprets CPU and profiling results.

[rb07]

Kernel and CPU: Linux 2.6.32-31-generic on x86_64
Processor information: Intel(R) Atom(TM) CPU D425 @ 1.80GHz, 2 cores

The processor is not a 2 cores processor, its one of those Intel hyper-whatever (threads I think they call them), the D525 is the one with 2 cores. Ref: Intel And the kernel appears to be single core (which is correct), but was it optimized for Intel Atom?

Was Transmission compiled as 64-bit?

You are probably comparing your PC with a powerful processor to an Atom based computer, they are really on different leagues (as good as the Atom is).

[ross105]

Ubuntu detects it as two-cored, but it has only one. I think CPU is not a problem cause there's a lot of NAS-es and other servers that have primitive CPU and do work fine
Previous builds of transmission worked ok on my server. Transmission wasn't compiled - it was installed from PPA and ubuntu decided by itself what package will fit.