I'm using svn 1020533 and ktorrent after a while slows down a lot and eats around 75-80% of cpu.
GUI starts becomes also jerky, setting GUI update interval to higher number doesn't help.

I have only 3 active torrent, download is at 60KBps and upload 20KBps, too low to cause such problems.
CPU went into performance mode and it's generating a lot of heat under such conditions.
Known problem?

EDIT: router also says that I have open 1200 connections, but I've set hard limit to 150 in ktorrent. Seems like
this number is slowly increasing over time, maybe ktorrent is making a lot of new connections without closing them
properly and causing high cpu usage? Just a guess...

I'm not aware of any problems like this. Probably has something todo with some new features, I doubt it is to many peer connections, that code hasn't been touched the last couple of months.

Is resolve hostnames of peers enabled ?
Is DHT enabled ?

Those are pretty much the biggest changes lately with anything network related. The 1200 connections could be caused by DHT (though technically DHT doesn't setup any connections, it uses UDP, but NAT routers have to threat UDP packets as connections to do NAT)

Only dht is enabled from above features, so that explains connections number count.
Now I'm trying to reproduce that lag on freshly rebooted machine but I can't.
Seems like it was Xorg - I know it was using a lot of memory before shutdown, maybe
ktorrent interface redrawing was slow due to this. However cpu intensive was ktorrent process
not Xorg, don't know really why. Will try to reproduce, but it might take time.

I confirm the presence of this bug.
The bug disappears only disabling DHT (450 nodes, 15 processes).

Ktorrent 3.3 beta 1

Then we will have to take a look at it.

Ktorrent doesn't use dht if torrent uses private tracker?
That probably explains why I couldn't reproduce this after, I was using a private tracker.

Yes DHT is not used for private torrents.

I downloaded a couple of torrents this weekend, with DHT enabled, but didn't see any high CPU usage.

Were these hugely popular torrents you were downloading ? Mine had rather small swarms, so it might not have been very good test candidates to reproduce the problem.

i can confirm this, too. and i am fairly certain i isolated it to this commit:

Code: Select all

r1017049 | guisson | 2009-08-29 18:42:13 +0200 (Sa, 29. Aug 2009) | 6 lines

Improved DHT's ability to find peers :
- Removed some limits on tasks, so they should run longer
- Always start a node lookup for our own ID to refresh the table at startup
- Increase bucket size to 20                                               

BUG: 205346


_Eddi_ wrote:i can confirm this, too. and i am fairly certain i isolated it to this commit:

Code: Select all

r1017049 | guisson | 2009-08-29 18:42:13 +0200 (Sa, 29. Aug 2009) | 6 lines

Improved DHT's ability to find peers :
- Removed some limits on tasks, so they should run longer
- Always start a node lookup for our own ID to refresh the table at startup
- Increase bucket size to 20                                               

BUG: 205346


Seeing that is the only change to DHT in the last few months, that was also what I was looking at.

However, still haven't managed to reproduce it.

Revision: 1037186
Happened again, cpu usage around 60%, downloading 0 torrent, seeding 2.
Max upload speed is 25KB/s. Not much.

When problem occured, log was steadily increasing with such of lines:

Code: Select all

Mon Oct 19 06:55:19 2009: Pinging questionable node : 84.249.37.101:7085
Mon Oct 19 06:55:20 2009: DHT: Sending ping response
Mon Oct 19 06:55:20 2009: DHT: got getPeers request
Mon Oct 19 06:55:20 2009: DHT: got getPeers request
Mon Oct 19 06:55:20 2009: DHT: Sending ping response
Mon Oct 19 06:55:20 2009: DHT: got findNode request
Mon Oct 19 06:55:20 2009: DHT: got getPeers request
Mon Oct 19 06:55:21 2009: DHT: got getPeers request
Mon Oct 19 06:55:21 2009: DHT: got findNode request
Mon Oct 19 06:55:22 2009: DHT: got findNode request
Mon Oct 19 06:55:23 2009: Pinging questionable node : 173.183.185.214:25390
Mon Oct 19 06:55:24 2009: DHT: got findNode request
Mon Oct 19 06:55:24 2009: Pinging questionable node : 173.183.185.214:25390
Mon Oct 19 06:55:26 2009: DHT: got getPeers request
Mon Oct 19 06:55:28 2009: DHT: got getPeers request
Mon Oct 19 06:55:29 2009: DHT: got findNode request
Mon Oct 19 06:55:29 2009: DHT: got getPeers request
Mon Oct 19 06:55:29 2009: DHT: got findNode request
Mon Oct 19 06:55:29 2009: DHT: got getPeers request
Mon Oct 19 06:55:29 2009: DHT: Sending ping response
Mon Oct 19 06:55:30 2009: DHT: got findNode request
Mon Oct 19 06:55:30 2009: DHT: got getPeers request
Mon Oct 19 06:55:30 2009: Piece cache: memory in use 0 B, memory freed 16,0 KiB
Mon Oct 19 06:55:30 2009: DHT: got getPeers request
Mon Oct 19 06:55:30 2009: DHT: Sending ping response
Mon Oct 19 06:55:30 2009: DHT: got getPeers request
Mon Oct 19 06:55:31 2009: DHT: got getPeers request
Mon Oct 19 06:55:31 2009: DHT: got findNode request
Mon Oct 19 06:55:31 2009: DHT: got findNode request
Mon Oct 19 06:55:31 2009: DHT: got findNode request
Mon Oct 19 06:55:32 2009: DHT: got getPeers request

Any clues?
Restarting ktorrent fixed problem temporarily (like it always does).

Incoming DHT packets will be dealt with in a better way in 3.3rc1, but this doesn't mean it still might take a lot of CPU time to handle those packets.

Is this normal to get such ammount of DHT packets?
For now I've disabled dht completely - I don't see any benefits.

kriko wrote:Is this normal to get such ammount of DHT packets?

There is nothing in the DHT protocol which would prevent this. Could be a client misbehaving, it would be interesting to see where the packets come from.

Does wireshark trace helps? I captured traffic on dht port...
currently is 17% cpu usage, but dl speed is ridicuosly low.