which version to choose?

[lvm]

I was using deluge-gtk 1.3 on old ubuntu 18.04 with no issues whatsoever, but as 18.04 is no longer supported I've upgraded to 20.04 which provides deluge 2.0.3 in its repo and ran into a couple of bugs: first, it won't let me change destination folder for torrents being downloaded, second, toolbar shows icons even though it is configured to show as text. Ok, I tried the latest 2.1.1 from the PPA. The destination folder bug is fixed, toolbar bug is still there, and it turned into a CPU hog - 20-30% of the core when idle while older versions barely registered.

I am definitely not staying on 2.1.1 because of high CPU usage unless someone tells me how to tame it, but I'd rather not have this folder bug. So my question is: is it worth trying 2.0.5 - is the folder bug fixed there? or should I go back to 1.3 where it wasn't even introduced and the toolbars are nice too? And how does deluge likes downgrades? Will 1.3 work with 2.x configuration and state?

[mhertz]

The "folder bug" you mention, presumably is an issue with libtorrent 1.2.9 specifically, if remember correct, so guessing was used on your deluge 2.0.3 install(sorry to lazy to check now online), and so would be fixed by changing away from that, up or down.

The toolbar issue I responded in your other post, no solution however sadly, just info.

I would guess it's not related to deluge over 2.0.3 to have higher CPU, but just a guess. Rather i'd guess it's libtorrent or some other dep making this.

Going from deluge1 to deluge2 should be supported, but other way around not so much - keep backups of profile and all regardless, just in case. Ohh, I just remembered sometime after deluge2 released, a bug where state sometimes not transferred between deluge1 and deluge2, non-asci chars in torrent-names I believe, breaking it and clearing torrent-list, and was fixed later, but cannot remember in which version specifically, and again to lazy to check now, so again, backups important.

[lvm]

Thanks. 2.0.3 from ubuntu 20.04 repo which has this folder bug comes with libtorrent 1.1.13. https://packages.ubuntu.com/focal/libtorrent-rasterbar9

[lvm]

I've replaced libtorrent 1.2.16 from the PPA with 1.2.19 I built from source (BTW your build from source instruction here https://dev.deluge-torrent.org/wiki/Building/libtorrent doesn't mention the necessity of installing python3-setuptools and libboost-tools-dev) but as far as high CPU usage of 2.1.1 is concerned it changed nothing.

[mhertz]

Thanks for info, good job BTW

I didn't knew there also was a problem in 1.1.13, though maybe I misinterpreted the issue, which was a move_storage one in 1.2.9.

Im sorry I don't know why higher CPU, if was me then would use clean profile to make sure not some plugin or setting misbehaving. When googling higher cpu with Deluge, then mentioned also on 1.x, and for some was workarounded by deleting state folder, or copy back from it one at a time but nothing other really, though very quickly searched only. Generally running deluged in thinclient mode, only opening gtk-ui when needed, momentarily, is a good idea if not already. Then I'd make a venv of previous deluge version, and see if same issue there, and try further pinpoint, as I presume is dep related still then, as nothing inherently changed in deluge regarding this, I believe, to warrant this by itself. Yesterday I checked very quickly, and had roughly same cpu idle in deluge1 and deluge2, though no torrents loaded there, was little lazy there honestly. You can downtune libtorrent from deluge itself and/or ltconfig plugin, but shouldn't really be needed as default setup Isnt too aggressive as to warrant such behavior, and hence suspect elsewhere culprit. Maybe libtorrent 1.1.x is little lighter, but such big diff not sounding plausible, so probably not that, and regardless 1.1.x unsupported in newest deluge versions anyway.

Sorry couldn't help you mate.

[ambipro]

I'm not sure what hardware you are running on, but I'm running 2.1.1 in docker on unraid (linux). With several thousand torrents seeding and 10+ other containers running I don't see usage much past peaks of 15-20% except when something is significantly uploading (5MB/s+)

What you're describing seems to be potentially an issue "outside" of deluge itself, as mhertz said it could be a dependency doing this.

As you didn't give your hardware specs or torrent count, I can't say if your system is "underpowered" (celeron/athlon/etc)- but my assumption is its probably newer than mine (mine is i7-2600k) and likely less torrents.

Unfortunately, I don't know of a good way to troubleshoot this issue, but a few things you can try that were briefly mentioned are running deluge strictly in daemon mode, and using thin client. See if you have this level of usage when thin client is closed and it's just daemon, that could tell you if it is GUI related (GTK), try different libtorrent versions, and maybe look into ltconfig plugin to customize things more specifically.

[mhertz]

Thanks ambipro

Anyway, @lvm, just wanted quickly add that I didn't was able to reproduce myself in quick testing i.e. downloaded and fired up new VM with latest ubuntu 20.04 live-iso, installed and tested deluged/libtorrent 2.0.3/1.1.13, plus same afterwards with ppa's deluge/libtorrent 2.1.1/1.2.16, and both lingered at 0.7 - 1.0% and then roughly once a minute wen't up to spikes between 2 and 9, mostly between 2-3 though. Only a single finished torrent running though, and on a live-cd, but still. Just adding for completeness.

[lvm]

Ok, I tried thin mode, fixed the "ee key too small" issue, and now I can tell that it is deluged which is responsible for high CPU usage, client uses almost nothing.

I am seeding ~400 torrents on AMD phenom II X4, but don't know how it will help - the fact remains that 2.0.3 and 1.3 where well in single digits in the same conditions.

state directory looks ok to me - torrents.fastresume is 2M in size, torrent.state is 300K and 400 torrent files as it should be. Actually I had to re-create fastresume file some time ago while still on 1.3 when it grew in size to something completely unrealistic, but even then CPU usage remained low with infrequent spikes, I noticed it only because of growing backup size.

[ambipro]

If you're willing to go through a "hassle" - I'd try and 'mv' (rename) your deluge data/config directory and start fresh and load the same torrents. It will generate a new directory and default config when its ran. See if the behavior persists on a "fresh config", there may be something specific to blame.

Leave the preferences and settings as vanilla as you can, except for Queue, Bandwidth, and Downloads, (and required things like Daemon and WebUI) - and then see if the behavior persists.

This is not normal behavior, and seeing as that processor is more or less from the same period as mine, it seems like something else is going on. As I said, I have over 10x the torrents you have, and even when its pumping out 5-10MB/s on multiple torrents - with all 12 other containers active - I see under 30%.

As a note, I would add all the torrents with Skip Hash Check - because otherwise you're going to be waiting a long time and I assume your data is intact :P

[lvm]

My torrents are spread across multiple directories, re-adding them would be too much of a trouble, so no. I did run it with a debug log and profiler though but it doesn't say much to me, maybe it will to you? Profiler puts blame on polling of select.epoll objects with no further detail

deluge-CPU.png (69.56 KiB) Viewed 1905 times

and debug log consists of handling of session_stats_alert 2-4 times a second - isn't it a bit high?

Code: Select all

18:50:28 [DEBUG   ][deluge.core.alertmanager      :108 ] Alerts queued: 1
18:50:28 [DEBUG   ][deluge.core.alertmanager      :120 ] session_stats_alert: session stats (300 values): 5, 2470, 518, 21, 3, 0, 0, 0, 0, 1, 21, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 8, 0, 0, 13, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 764, 1024, 0, 0, 1, 774, 38, 0, 1128, 4635, 632, 0, 493, 751, 4916, 4229, 233, 0, 0, 4821, 582, 0, 570, 0, 0, 0, 1, 0, 74, 317, 0, 0, 0, 9, 0, 0, 0, 0, 0, 988, 0, 0, 988, 120, 1099, 0, 0, 0, 682, 0, 0, 0, 0, 0, 447, 0, 0, 0, 1098, 0, 0, 0, 1243391, 0, 1243391, 1365735, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1189522, 465400, 783408, 0, 824043, 395000, 68773, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1355, 4766, 5166, 0, 297, 1, 1763, 1918, 1987, 0, 45, 127, 3, 24, 1197, 631, 1531, 597, 118, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 517, 201, 340, 2551, 1661, 976, 98, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 62, 0, 335, 0, 0, 0, 0, 11, 0, 0, 30, 0, 0, 0, 0, 0, 21, 20, 1, 0, 3, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 15, 15, 8, 2, 5, 2, 0
18:50:28 [DEBUG   ][deluge.core.alertmanager      :125 ] Handling alert: session_stats_alert
18:50:28 [DEBUG   ][deluge.core.alertmanager      :108 ] Alerts queued: 1
18:50:28 [DEBUG   ][deluge.core.alertmanager      :120 ] session_stats_alert: session stats (300 values): 5, 2480, 519, 21, 3, 0, 0, 0, 0, 1, 21, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 9, 0, 0, 14, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 769, 1026, 0, 0, 1, 779, 38, 0, 1144, 4694, 632, 0, 507, 756, 4932, 4249, 234, 0, 0, 4830, 586, 0, 570, 0, 0, 0, 1, 0, 74, 318, 0, 0, 0, 9, 0, 0, 0, 0, 0, 989, 0, 0, 989, 123, 1102, 0, 0, 0, 685, 0, 0, 0, 0, 0, 447, 0, 0, 0, 1101, 0, 0, 0, 1243391, 0, 1243391, 1365735, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1195846, 467440, 783408, 0, 826096, 396400, 68773, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1363, 4775, 5177, 0, 298, 1, 1765, 1921, 1992, 0, 45, 130, 3, 24, 1198, 634, 1536, 605, 118, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 517, 202, 340, 2562, 1666, 980, 98, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 62, 0, 335, 0, 0, 0, 0, 22, 0, 0, 32, 0, 0, 0, 0, 0, 23, 29, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 14, 17, 6, 3, 4, 2, 0
18:50:28 [DEBUG   ][deluge.core.alertmanager      :125 ] Handling alert: session_stats_alert
18:50:28 [DEBUG   ][deluge.core.alertmanager      :108 ] Alerts queued: 1
18:50:28 [DEBUG   ][deluge.core.alertmanager      :120 ] session_stats_alert: session stats (300 values): 5, 2495, 521, 22, 3, 0, 0, 0, 0, 1, 21, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 9, 0, 0, 14, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 770, 1037, 0, 0, 1, 780, 38, 0, 1144, 4694, 632, 0, 507, 756, 4974, 4285, 235, 0, 0, 4861, 586, 0, 570, 0, 0, 0, 1, 0, 74, 322, 0, 0, 0, 9, 0, 0, 0, 0, 0, 1000, 0, 0, 1000, 123, 1113, 0, 0, 0, 692, 0, 0, 0, 0, 0, 451, 0, 0, 0, 1112, 0, 0, 0, 1243391, 0, 1243391, 1365735, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1204095, 471200, 783408, 0, 835700, 400160, 68773, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1368, 4809, 5208, 0, 298, 1, 1779, 1934, 2004, 0, 45, 130, 3, 24, 1216, 636, 1549, 608, 118, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 521, 203, 341, 2580, 1684, 992, 98, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 62, 0, 335, 0, 0, 0, 0, 11, 0, 0, 26, 0, 0, 0, 0, 0, 18, 19, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 10, 16, 3, 4, 1, 2, 0