Transmission still hangs horribly

[MadJens]

Found the problem.
It's something that takes care of torrent parts.
When downloading smaller torrents with parts around 2000-3000 then everything goes nice (CPU usage for transmission is ~60-80%), but with higher part counts (say ~16000) things go totally wrong (download speeds are low and CPU usage is maxed out).

I have exactly (!!!) that problem when I'm downloading. What can be done about it?

[szafran]

Found the problem.
It's something that takes care of torrent parts.
When downloading smaller torrents with parts around 2000-3000 then everything goes nice (CPU usage for transmission is ~60-80%), but with higher part counts (say ~16000) things go totally wrong (download speeds are low and CPU usage is maxed out).

I have exactly (!!!) that problem when I'm downloading. What can be done about it?

I don't know - haven't found anything that could help.
10-20mbps and Transmission works fine doesn't matter what's the number of parts.
Speeds above that and the problems start.
I've tried many different config options. Nothing helps - so the only thing we can do is just wait for the devs to correct that.

[Jordan]

This dev isn't seeing that behavior, so without more information nothing's going to happen.

You may want to try running a debug build of Transmission in a debugger and manually getting a backtrace in the middle of a hang... which is kind of a pain, but unless you have a better idea... :/

$ sudo apt-get install transmission-dbg
$ gdb transmission-gtk
(gdb) handle SIGPIPE nostop noprint pass
(gdb) r
# then wait for the freeze. WHEN THE FREEZE OCCURS, hit ctrl-c to interrupt the program & get a gdb prompt:
(gdb) thread apply all bt
# and then pastebin the output and post a link here.

[szafran]

This dev isn't seeing that behavior, so without more information nothing's going to happen.

You may want to try running a debug build of Transmission in a debugger and manually getting a backtrace in the middle of a hang... which is kind of a pain, but unless you have a better idea... :/

$ sudo apt-get install transmission-dbg
$ gdb transmission-gtk
(gdb) handle SIGPIPE nostop noprint pass
(gdb) r
# then wait for the freeze. WHEN THE FREEZE OCCURS, hit ctrl-c to interrupt the program & get a gdb prompt:
(gdb) thread apply all bt
# and then pastebin the output and post a link here.

That will be tricky to time it exactly at the hang point.
I'm using an svn build - do i need to install the transmission-dbg or just build with some additional switches ? (or maybe svn builds always as dbg)

[Jordan]

If you pull from the svn trunk branch, the executables built there will have debug symbols up until the "make install" step. The only time I run "make install" during testing/debugging is when there's a bug report about the install rules

Building from an svn stable branch will be less useful, since our autoconf file has rules to remove some of the debugging bells & whistles in the stable builds.

But still, building your own is a huge plus for debugging. The non-debug versions that come from the distro are the least useful at all in that respect.

[szafran]

Yes, I'm pulling from trunk.
I think that I'll be able to play with it on the weekend.
But I haven't had the time to look closer at the files, so I'll need some hints on what to do after running 'make' (eg. do i need to 'make uninstall' first ?)

But till the weekend comes, I've managed to make a screenshot of htop with transmission working. It's not working at 100% CPU on it, but that's the same thread. After running transmission-gtk it creates main thread, and then 3 sub-threads, and the one making problems is always the middle (second) sub-thread (at 29% CPU on the screenshot). Hope that can make some more things clear untill I'll make a debug log.

[szafran]

I've tried to make something with it, but I've found only a torrent that had max transfers ~2,5MB/s and only ~9k parts.
I've ctrl+c on it when it was at ~95% CPU and the speed went down.

Hope you can use it:
http://pastebin.com/KetnLZsv

[szafran]

I've just realised that the current svn version cuts the speed of the dls to ~2MB/s - doesn't matter what's downloading (and what's set in the options)

[Jordan]

I've tried to make something with it, but I've found only a torrent that had max transfers ~2,5MB/s and only ~9k parts.
I've ctrl+c on it when it was at ~95% CPU and the speed went down.

Hope you can use it:
http://pastebin.com/KetnLZsv

In this pastebin, Transmission is busy running assertions that only exist in the nightly builds. Try rebuilding after adding "-DNDEBUG" to libtransmission/Makefile's CPPFLAGS if you don't want the nightly build's runtime assertions.

[szafran]

Added -DNDEBUG, and:
http://pastebin.com/UgB5piQS

cache is at 512MB, short time after it fulls up the CPU usage goes up and the speed goes down (from 7,5MB/s to about 2MB/s).
This time the torrent is pretty small - around 3,5GB size and about 3,5k parts.

P.S. Sorry but I accidentially pasted it with my build log.

[szafran]

On a torrent with 390GB size and 23,273 parts I'm getting only up to 600kB/s (that's less than 10% of what it should be) and the CPU usage is maxed out all the time.
I'll pull an update and do a debug dump later today.

[szafran]

Sorry, but no go with the dump. While in debug session the speeds are still only about 600kB/s, but the CPU usage is much lower.
Don't really know how that's possible - with the same compile I do 'make install' and run it then the speeds are the same and the CPU usage goes to the max.

[Jordan]

On a torrent with 390GB size and 23,273 parts I'm getting only up to 600kB/s (that's less than 10% of what it should be) and the CPU usage is maxed out all the time.
I'll pull an update and do a debug dump later today.

600kB/s is less than 10% the speed you're expecting?

[blacke4dawn]

On a torrent with 390GB size and 23,273 parts I'm getting only up to 600kB/s (that's less than 10% of what it should be) and the CPU usage is maxed out all the time.
I'll pull an update and do a debug dump later today.

I'm very interested to know how you are able to calculate what the speed should be considering that you nothing about the other peers upload capability and current load. Note that this is very different from the speed you have available to you for downloading data.

[szafran]

On a torrent with 390GB size and 23,273 parts I'm getting only up to 600kB/s (that's less than 10% of what it should be) and the CPU usage is maxed out all the time.
I'll pull an update and do a debug dump later today.

I'm very interested to know how you are able to calculate what the speed should be considering that you nothing about the other peers upload capability and current load. Note that this is very different from the speed you have available to you for downloading data.

Read the whole topic - I do compare it to the speeds I can achieve on a much slower laptop with Win7 + uT (so what you wrote doesn't make sense). In addition the whole app chokes, every few seconds (for a couple of more seconds) it stops responding (via gtk frontend and www frontend). These chokes are at the same time that the app goes 100% CPU (the rest of the time it's about 95-98% CPU).