Deluge Forum

shirish wrote:

plisk wrote:Tares, shirish: and this CPU load is on 0.5.3 RC1, not on 0.5.2, right ?

Tares: if you download not so many torrents at a time could you send me a link to 1 torrent that causes this behaviour so i can check how it's behaves here ? Also would be good to gather on IRC while doing this so we can discuss this in real time, this way it'll be faster resolved.

BTW, about encryption enabled - propably yes, this can be related. I have to check some specific torrent first to see for myself this behaviour, then we can decide what to do. And more - could you then try to limit max download speed to some not so big value like 10KB/s and see if anything changes ?

plisk, the load is on 0.5.3 RC1 , actually svn 1041 . I came down to 10 Kbps (DL) but still no change in the CPU, its still fluctuating between 23-30% . I observed the cycle for 5 full minutes (in htop) . Please lemme know if you need more info. Maybe this is also related with a .torrent file having many parts (.rar parts). Finding one or more .torrent files having multiple parts is no issue at all.

Hm.. The only thing i could think of while Tares didn't answer - is to try to backup your ~.config/deluge dir and start to remove torrents from queue and see what happens. Try to play with queue and see maybe you could find a 1-2 of torrents that cause CPU usage. If you find them - i'd like to see them . Maybe it depends on state of torrents - paused/downloading/etc. Also interesting to know what will be with empty queue.

plisk wrote:Tares, shirish: and this CPU load is on 0.5.3 RC1, not on 0.5.2, right ?

Tares: if you download not so many torrents at a time could you send me a link to 1 torrent that causes this behaviour so i can check how it's behaves here ? Also would be good to gather on IRC while doing this so we can discuss this in real time, this way it'll be faster resolved.

BTW, about encryption enabled - propably yes, this can be related. I have to check some specific torrent first to see for myself this behaviour, then we can decide what to do. And more - could you then try to limit max download speed to some not so big value like 10KB/s and see if anything changes ?

Correct, 0.5.3 RC1 from tar.gz, I never know if which version from svn is already RC Encryption enabled.

Well, I've tried what you've suggested... to limit my download speed... I've done that through tray icon and guess what... deluge took my whole CPU usage. I've waited for a bit to see if this changes, but nothing happened till I've returned my limit to nothing.

About torrent's I'm usually downloading anime from tokyotosho.info As for now I cant remember which torrent caused that behaviour, but I got one that makes my torrent take ~10% CPU.

I would be updating the post in a while so please wait. First i backed up the .config/deluge & then removed .config/deluge so now deluge is empty . Now Deluge is nowhere in the picture :-
memory usage increased to 8% from 6.1 after blocklist importer has imported something like 200000+ entries. Encryption is enabled.

With the first .torrent file itself it jumped to 5% . While I can't give the .torrent file as it has my pass-key I can give the link of the .torrent file. http://bitnation.com/details.php?id=11347&hit=1 Connections are 2 (this will go & up & down as time passes) .

Memory holds steady, while CPU fluctuates. C*= Connections f*=files

With 3 files it is fluctuating between 5% to 10%. Connections now at 3

With 6 files CPU 10-15% mem 9% C* now 5 Connections 5

With 8 f" CPU 10-20% mem 10.1% C* now at 6

With the 9th f* CPU is 15-23% mem 10.1% C* now increased to 8 the .torrent file of this one http://www.demonoid.com/files/details/443062/2589020/

With 11 f* CPU is 18-28% mem 10.3% Connections now at 10-11.

With 14 f* CPU is 20-30% mem 11% Connections now at 15

With 16f* CPU is 23-33% mem 11% Connections now 15-20.

With 18 f* CPU is 27-37% mem 11% Connections 17-20

Updates finished.

Notes :- Some notes for consideration

Now instead of removing the .torrent files. I removed .config/deluge & made a clean start.
blocklist importer was the 1st thing which was imported & remained in the session throughout.
Htop was made running throughout the operation in a tree fashion so fluctuations don't affect the place where deluge is showed.
Download is/was capped at 10 Kbps for download while upload was capped at 4% , much less than what it can play with .
The files were checked & then htop was looked for fluctuating activity for 3-5 minutes & average ratios were given. Sometimes
there were some spikes but were dis-regarded.
The whole testing operation took almost 1.5 hrs. to complete.

Observations :- There seems to be a gradual increase & no sudden hikes unless the 1st one whould be seen as slightly bloated (as far as CPU usage is concerned) otherwise it has been a gradual manner. I have no idea why the overheads as far as CPU is concerned creep so much?

Please lemme know if more info. is needed. Cheers!

Thanks guys for stats, one more thing would draw the whole picture. Try to run deluge this way for 5-10 minutes while actively downloading then exit it and upload /tmp/deluge_cpu_stats.log file here as an attach:

python -m cProfile -s cumulative /usr/bin/deluge > /tmp/deluge_cpu_stats.log

plisk, would do that but tomorrow morning as its already 3:30 a.m. here.
Its fun & I'm sure will learn something more about python stuff also with this

plisk wrote:Thanks guys for stats, one more thing would draw the whole picture. Try to run deluge this way for 5-10 minutes while actively downloading then exit it and upload /tmp/deluge_cpu_stats.txt file here as an attach:

python -m cProfile -s cumulative /usr/bin/deluge > /tmp/deluge_cpu_stats.txt

plisk, guess you forgot to first say install python profiler as I hadn't installed or maybe its an issue with python itself for I got this traceback, callback.
If its an issue with python itself then would report it at launchpad. if its because python-profiler wasn't installed would know in couple of minutes as also installing that & trying it again. Sorry for the trouble.

It was because python-profiler was not installed. I installed it.
While you asked for 15-20 minutes, I give something close to 45 minutes worth of stuff. This is with svn 1047 Don't envy you going through all this pain

Btw the extension .txt, csv, odt & pdf is not allowed by either phpBB 3.0 RC3 or maybe zachtib has not configured it or some other reason.

http://rapidshare.com/files/43937010/de ... s.odt.html

http://rapidshare.com/files/43937165/de ... s.txt.html

please try current svn r1050 as I made a patch that will not run gui updating code when it's minimized or hidden in tray. Hopefully you can see improvements this way until/if we can sort out the other issues

Thanks shirish, i'll take a look into this stats.

Well, after some research the main issue here is in not so good performance of gtk's tree view widget that is used to display list of torrents. On each update of speeds, progress, status etc of torrents we update the content's of tree view widget and here is where the bottleneck is. As soon as updates of torrents info removed CPU utilization is down to 0%. What to do with all this i haven't decided yet, there is some hacks of custom widgets for grid like display of data that supposed to overcome performance issues of tree view widget but they are hacks and to actually use them you have to play with them to fit it to deluge..

Well, in the end it's a priority issue now for me and we'll see that this all results in.