mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
4.2.5 takes half an hour to load UI #10431
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#10431
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ned-martin on GitHub (May 12, 2020).
qBittorrent version and Operating System
v4.2.5 x64
Windows 10 (running virtualised under Hyper-V)
What is the problem
After updating to 4.2.* versions a few times and finding them to vary between unstable and unusable, I made the mistake of updating again today - this time to 4.2.5 from 4.1.9.1
It takes about half an hour to load the UI. A blank white/grey "qBittorrent v4.2.5 (Not Responding) " window loads up, and then half an hour later (I'm not joking!), starts responding. By the time it's responding, it has built up a commit size of over 12 GB, but only 500MB or so working set.
I'm not really sure what else to check. Process Explorer says it's opened a large amount of connections, so it would appear that it may actually be functioning while the UI is non-responsive. There is very little disk IO.
What is the expected behavior
Program opens a responsive UI in a timely manner and does not use 12 GB RAM.
Steps to reproduce
Upgrade from 4.1.9.1 with many existing torrents and then try to open v4.2.5
Additional Info
@ned-martin commented on GitHub (May 12, 2020):
Unfortunately, I can confirm that this does not work.
@ned-martin commented on GitHub (May 12, 2020):
qBittorrent had reached 28GB RAM (commit) usage, which hits the limit of the 32GB RAM in the machine it's running in, so I had to close it and re-open it. It's currently non-responsive. In theory, in half an hour or so, it'll become responsive and load the UI.
Point being, that there's also some serious memory issues, along with the serious loading/UI issues.
@ghost commented on GitHub (May 13, 2020):
Faced same issue since 4.2.2. White qBt screen with Not responding in title. Though I didn't face it on startup. Usually it happens after running for some time with lot of download/upload activity going on. There's definitely a memory leak issue.
@xavier2k6 commented on GitHub (May 13, 2020):
It may have been due to checking/re-checking torrents too.....
From 4.2.0 onwards!
If you want to try another 4.2.5 build, then you can try https://github.com/qbittorrent/qBittorrent/issues/12652#issuecomment-626385890
This was built with latest libtorrent commit/Boost 1.73 & Qt 5.14.2 at time of compilation.
@FranciscoPombal commented on GitHub (May 13, 2020):
There is in fact a memory leak related to HTTPS tracker connections in libtorrent that affects some people: https://github.com/qbittorrent/qBittorrent/issues/12326
But it does not have to do with UI slowdowns (at least that's not been reported as a symptom related to that problem).
So this memory leak you are experiencing is most likely due to something else.
@ghost commented on GitHub (May 13, 2020):
That rechecking happens only on downgrades. You can update without any sort of rechecks.
@xavier2k6 commented on GitHub (May 13, 2020):
I know that but.........
I took that as they they were on 4.2.x series, downgraded to 4.1.9.1 & then went back to 4.2.5.
It's not exactly clear in what kind of time frame this was done......straight away/after a few hours/after a few days etc.
There's a test build in my previous post anyway to try out.
@ned-martin commented on GitHub (May 13, 2020):
I can confirm that no torrents are being rechecked.
I'm finding it difficult to understand how I can be the only one experiencing this problem. I can't see how my situation is different. The only remotely non-standard aspect of my install is that the torrents themselves are stored on a network share, and the machine has local swap disabled (i.e. RAM only - no swapping to disk). The local config, .torrent and .fastresume files, etc. are all stored in their default locations.
I deleted my settings and tried defaults - same problem. Opening qBittorrent results in the UI being non-responsive for around half an hour, and once it responds it's committed about 8GB of RAM, which then slowly builds up to 28GB (the limit it can reach on my machine) over the next several hours.
I have approx 1,800 torrents in the client - is it perhaps just not possible to use qBittorrent anymore unless you only have a handful of torrents?
@FranciscoPombal commented on GitHub (May 13, 2020):
@ned-martin
Have you tried without the network share? It should not be a problem, but your whole situation is quite strange, so might as well try that.
No, qBittorrent can easily handle several thousands of torrents.
@ned-martin commented on GitHub (May 13, 2020):
I can confirm that this version does not appear to be any different, other than making a lot of empty mat-debug-*.log's. It is currently non-responding. I'm guessing in half an hour it'll load the UI.
@ned-martin commented on GitHub (May 13, 2020):
Surely using a network share is not a "strange" situation? Either way, no, unfortunately I cannot try without it.
In case it wasn't apparent - with no torrents (i.e. a clean empty install) qBittorrent opens immediately. I haven't bothered downloading anything in it but I imagine it'd work just fine. But with my torrents loaded, it takes half-an-hour-ish to open and exhibits the aforementioned problems.
I can't try with my torrents loaded without using a network share (because that's where the torrents are stored - and it's where the fastresume files point at, so even if I did have the spare storage to somehow copy the torrents across to a local disk, I don't know how to make it do that).
I can try without a network share with no torrents, but then that doesn't seem to be helpful as it's just an empty install at that stage.
For what it's worth, the network share is on a virtual 10-gigE connection, so there's effectively no latency or bottlenecks there. I've looked at disk queues and so forth, both locally and on the network share disks, and nothing seems to be a bottleneck. There doesn't appear to be any excessive use of anything - it's just sitting there very slowly doing "something" until it has loaded 8GB or so and then the UI will become responsive.
Then once it's responsive, it works fine until it uses up all the available RAM, at which point it will eventually crash.
@xavier2k6 commented on GitHub (May 13, 2020):
Snippet from #11348
Is this still the case with your current setup?
@ned-martin commented on GitHub (May 13, 2020):
No, at this stage I have disabled disk cache, and every other form of caching I could find.
However, I have tried with it both enabled, disabled, and random different values, without any noticeable change.
Attached is my current ini file.
qBittorrent.ini.log
@xavier2k6 commented on GitHub (May 15, 2020):
Try enabling/setting the following in qBittorrent's advanced settings:
Enable OS Cache -> yes (tick)
Coalesce reads & writes -> yes (tick)
Disk Cache -> -1 (auto)
Is pagefile disabled in your OS?
The logs you say are being created with the build I provided seem to point to a driver issue?!
Anybody else that has used that build have reported no such logs being created.....
@ned-martin commented on GitHub (May 15, 2020):
I have set the settings like you said, however I believe that's probably how they were at the start before I tried changing everything. I tried disabling everything that seemed like it might cause some kind of delay (for example, I turned off resolve DNS etc.)
The log files are empty files named like mat-debug-7952.log, apart from aria-debug-9184.log which contains the following:
2020-05-15 01:32:53.487|00003816| C:\build\aria-cpp-v1\clienttelemetry\src\LogManagerImpl.cpp(626): class Microsoft::Applications::Telemetry::ILogger *__thiscall Microsoft::Applications::Telemetry::LogManagerImpl::Initialize(const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &,const struct Microsoft::Applications::Telemetry::LogConfiguration &) WARNING: Invalid in-ram queue size (20971520), adjusted to max ram queue sizeYes, pagefile is disabled.
The OS is Windows 10 x64 with 48GB RAM (it was 32GB when I logged the issue but I've increased it - I also tried decreasing it to 16GB in case that was somehow relevant). It is virtualised on Hyper-V, and the downloaded data is stored on a network share. It confuses me that I'm seemingly the only one having this issue, as it's a very normal Windows 10 install. Nothing else installed. The hardware and drivers are as generic as possible - because it's virtualised.
The only non-standard things I can think of are:
I imagine they're related, but there seems to be two problems:
Let me know if there is any data I can give you that may be of use to troubleshoot this.
@FranciscoPombal commented on GitHub (May 15, 2020):
Those aren't fastresume files and those logs do not belong to qBittorrent.
@Phooh commented on GitHub (May 15, 2020):
I'm recently having the same issue here on Windows 7. I had no issues with 4.2.5 until today as I've been using it since it was released. Now I can't even start up qBittorent anymore. The UI just hangs at a white screen and my old laptop will slow down to a crawl.
Don't know what else to show other than this spiking that keeps rising the longer I leave it running.
@ned-martin commented on GitHub (May 15, 2020):
They are either fastresume files or torrents, I can't tell the difference, but when I open them in a text editor, they look the same as fastresume files to me, and contain data about the torrents I'm using. I have jackett installed and used as a search provider for qBittorrent, so maybe it creates them? Either way, not relevant to this issue I guess.
The logs I have no idea about - @xavier2k6 mentioned them so I put a screenshot to confirm that's what he's talking about. If they're not from qBittorent, kind of curious to know where they are from, but I guess not relevant to this issue then.
@xavier2k6 commented on GitHub (May 17, 2020):
@Phooh >If you want to try another 4.2.5 build, then you can try https://github.com/qbittorrent/qBittorrent/issues/12652#issuecomment-626385890
This was built with latest libtorrent commit/Boost 1.73 & Qt 5.14.2 at time of compilation.
@ned-martin How is this build & the new settings working out for you now?
I think that having your pagefile disabled could potentially be a problem.
@Phooh commented on GitHub (May 17, 2020):
@xavier2k6 I was able to see the UI but once I told it "Yes" to allow it to associate with torrent files and magnet links, it went back to freezing and having large spikes. So basically nothings changed on my end. I restarted the program and it went back to freezing at a white screen with no UI.
I then tried unzipping the build again to revert back so I can get the option to associate with torrent files and magnet links and this time clicked "No" and then it starting showing my torrents but then ended up freezing and spiking.
@xavier2k6 commented on GitHub (May 17, 2020):
@Phooh how many torrents do you have? & how long did you let the test build run before you closed it?
@ned-martin commented on GitHub (May 17, 2020):
There has been no noticeable change using this build, or with those settings. Starting qBittorrent results in this (see below) for a considerable amount of time:
Once the "Commit size" column in Task Manager gets to around 8 GB, the UI will start working. My non-technical assumption is that it's finished "loading" all the torrents into RAM at that stage. However, whatever delay is causing it to do this so slowly is not apparent to me - there is no CPU, disk queue or network issues that I can see. As you can see from the below, there's no apparent performance bottlenecks:
Note that during this time while the UI is frozen, qBittorrent is still establishing large numbers of connections to remote addresses, so it appears to be doing something. My assumption is that the only part of the process that can be slow enough to cause this kind of extreme delay during start-up is network connections - it's doing something like waiting on connections to trackers to timeout for every torrent each time it loads the torrent into the UI, or something like that.
After several hours qBittorrent will have consumed all available memory, at which point either it will freeze or crash, or some other part of Windows will crash due to no memory, and the system will often become unstable and need to be rebooted.
I have enabled a pagefile. It has made no noticeable change other perhaps than making the UI a bit slower - I assume it's swapping stuff back to RAM from slower disk. But realistically, no noticeable change. It has definitely not corrected either of the two issues I'm facing - the half hour load of the UI, or the fact that it uses all available RAM in a matter of hours.
@ned-martin commented on GitHub (May 17, 2020):
If I set qBittorrent's affinity to one core (or in this case, virtual CPU), it does use the entire CPU, so it is perhaps CPU bound. When not locked to a single CPU, it does seem to multithread across all 4 just fine without hitting any limits however. Resource Monitor says it's using about 25% CPU, which while perhaps excessive, should be fine.
qBittorrent bound to one CPU core:
qBittorrent allowed to use all cores:
@ned-martin commented on GitHub (May 18, 2020):
It just finished "loading" or whatever it does, so I can confirm it took exactly 37 minutes from starting, to having a non-frozen UI, and is using about 6GB RAM (which will continually go up over time). Note that this is using the beta build linked above, but I don't think there's any difference between that build and the official 4.2.5 build in this regard.
@Phooh commented on GitHub (May 18, 2020):
@xavier2k6 At least 30 something, some of them are magnet links and some are from a torrent files. As for how long I left the test build running, maybe like a couple of minutes. I try not to leave it running for too long due to this laptop I'm using isn't really that good. Its an HP with an Intel Pentium J3710 CPU with some generic Intel GPU, all running on 8GB of RAM.
I could try letting it run for longer but the problem when the test build or qBittorrent is running is, everything starts to slow down for me to where even the music I'm playing is sounding like its tearing up and that kind of worries me because usually if something like this happens, it means my laptop is about to crash.
@xavier2k6 commented on GitHub (May 19, 2020):
@ned-martin your network speeds seem a bit low for 10Gbe? (I could be mistaken or was very little network traffic when you took screenshots)
You seem to have edited previous posts with alot more info/screenshots too & unfortunately at this moment in time, I don't have the spare time to review/advise.
@ned-martin commented on GitHub (May 20, 2020):
I imagine there's not much network activity going on, considering qBittorrent is non-responsive at the time.
The network is virtual 10GbE, it's the link between the network attached disk and the virtual machine, i.e. it's what qBittorrent will be using to store its downloads, using standard Windows file shares / SMB2/SMB3 (SMB1 is not enabled). The network to the internet is via a VPN at a much slower speed than 10Gb.
@bksinn78 commented on GitHub (May 20, 2020):
I have the same problem had the freezing during startup for a while but once it got going it was good
now after the initial freeze it works OK then it freezes up again on and off almost unusable I'm on windows server 2016 i have 7900ish torrents
@xavier2k6 commented on GitHub (May 22, 2020):
Try this build below:
Windows test build of 4.2.5 with listed libraries:
Download Link
@xavier2k6 commented on GitHub (May 22, 2020):
Another build below you can try is compiled from master:
Windows test build of 4.3.0(Alpha1) with listed libraries:
Download Link
@bksinn78 commented on GitHub (May 22, 2020):
thank you will give it a try and post back
@bksinn78 commented on GitHub (May 24, 2020):
Still have the same issue with these :(
@ned-martin commented on GitHub (May 24, 2020):
v4.3.0alpha1 took 18 minutes before the UI became responsive (I haven't timed it before, but I imagine this is about the same amount of time as the previous version/s took)
@xavier2k6 commented on GitHub (May 24, 2020):
@ned-martin how many torrents do you have?
@ned-martin commented on GitHub (May 24, 2020):
1800
@xavier2k6 commented on GitHub (May 24, 2020):
Can you both change your file pool size in advanced settings from 40 to 2000 & see if that helps.
Also,
what do ye have set for
transfer list refresh interval?do ye have
use alternating row colorschecked or unchecked under options->behavior?@bksinn78 commented on GitHub (May 24, 2020):
changed file pool size to 2000
transfer list refresh interval 1500 ms
use alternating row colors is checked
@bksinn78 commented on GitHub (May 24, 2020):
after changing pool size still have the same issue do you think its because of the number of torrents i have?
@FranciscoPombal commented on GitHub (May 24, 2020):
No, qBIttorrent can easily handle thousands of torrents. The file pool size only concerns open file descriptors (antivirus can cause issues with this if set to too low).
@xavier2k6 commented on GitHub (May 24, 2020):
@FranciscoPombal wouldn't the logs probably provide a more accurate timeframe from when qBittorrent was started to when the last torrent was restored & any potential hiccups in between??
@bksinn78 can you provide some more info in regards to your setup, are you connecting to a NAS as well etc?
@bksinn78 commented on GitHub (May 24, 2020):
Negative 40tb array attached to my server
@ned-martin commented on GitHub (May 25, 2020):
4.3.0alpha1 with pool sized now changed from 40 to 2000 loaded faster - 12 minutes.
I'd still consider it unacceptable to have a frozen UI for 12 minutes, but it's a lot faster than 18 minutes.
I think the reality is probably that qBittorrent can't handle large numbers of torrents, and that anyone with a large number of torrents probably needs to be using a more robust client? People here say it can, but I've been using it for a few years, and I have yet to have any version that would run reliably for an extended period of time without user intervention. The newer versions are definitely a lot worse - I can't run this for more than 12 hours now without it using up all available RAM to the point that the system becomes unstable - but even the versions from over a year ago had similar problems.
Anyway, if there's any info I can give you that might help fix this, let me know.
@ghost commented on GitHub (May 25, 2020):
Libtorrent based clients can’t handle large amount of torrents. It wastes great amount of RAM and CPU cycles. Those who say it can, are seeding small torrents. I’ve tried both qbit and deluge with 7k torrents(48 TB) and both fail miserably. Whereas there are other clients(rtorrent) which handles it pretty easily.
@ned-martin commented on GitHub (May 25, 2020):
I understand this is not the place to promote what are effectively competitor's products, but at the same time, if I'm wasting my time on an assumption that a problem can be fixed when realistically it cannot, I'd like to know so I can investigate other alternatives, and ideally what alternatives would be most similar to qBittorrent (but, you know, working... :P)
I like the ease-of-use, UI, and integrated search of qBittorrent so ideally I'd like to continue using it if possible. I didn't find any other torrent clients that had the same features and ease-of-use.
@xavier2k6 commented on GitHub (May 25, 2020):
Can you try changing it to
8000@ned-martin commented on GitHub (May 25, 2020):
Using the times from the logs, with pool size 8000, it took 8 minutes from loading to the last torrent being restored and Python being detected (which I assume is when the UI becomes responsive - either way, nothing is logged after that)
With pool size 2000 it took 12 minutes.
I have only tried once each so far - I'll try a few more times tomorrow to make sure the difference is replicatable.
@xavier2k6 commented on GitHub (May 25, 2020):
Great - may be on to something here can you try
40000for the pool size?@ned-martin commented on GitHub (May 25, 2020):
10 minutes with 40,000. I'll retry all the values again tomorrow in case the time is actually just random or something. Don't have time to do that right now.
@FranciscoPombal commented on GitHub (May 25, 2020):
@an0n666
Admittedly, I have never tested with such a large amount of data, but I would say libtorrent should be able to handle it. Deluge and qBittorrent may be failing for other reasons - their GUIs may not be sufficiently optimized. For example, this is currently the case for qBittorrent's WebUI - the
syncis called every 2s and it is not nearly fast enough to work well with thousands of torrents. If you're only making sporadic calls to the API with something like curl, the story might be a bit different...It would also be helpful if you could specify a rough estimate of the number of files - 7k single file torrents is a very different story than 7k torrents totaling 100k files or something.
@arvidn what would be a good bare-bones client to really test libtorrent's performance with such a large number of torrents/files and file size? Is
client_testsufficiently performant in terms of TUI code that it could be a viable candidate for this?@FranciscoPombal commented on GitHub (May 25, 2020):
@arvidn
Also, what is the true impact of the file pool limit setting on non-Windows platforms? Does it work as a "max simultaneously open
fds" limit?@arvidn commented on GitHub (May 25, 2020):
Yes, that's what I use for my tests
@arvidn commented on GitHub (May 25, 2020):
It means the same on windows as unix. It doesn't exactly limit all file descriptors opened by libtorrent, it limits the file descriptors opened by the disk I/O subsystem. there's also the number of connections that use fds on unix.
So, it limits the number of simultaneously open files.
@FranciscoPombal commented on GitHub (May 26, 2020):
@arvidn
I see. Though for me it's a bit unclear what the docs mean by this then:
Isn't
40too low as a default? Doesn't a limit of 40 simultaneously open fds create a potential bottleneck? It would prevent files from being read/written to for people with many relatively active torrents. It seems with 100s of torrents, it would be pretty easy to run into a scenario where capacity would be wasted due to not being able to open more files for reading/writing at the same time.Could it also be bottlenecking rechecks in some way?
@arvidn commented on GitHub (May 26, 2020):
It's not obvious to me that it's loo low as a default. On MacOS, the default file descriptor limit is 255 per process (which I do think is too low for a default), but if you want 200 peer connections, there are only 50 fds left, and the run-time will use some too, and the client application.
Anyway, back to files. At the very beginning of libtorrent, before there was a file pool or a disk cache, I would open the file, read or write and close the file, for every 16 kiB request.
It worked great. It turns out opening files is really quick (this was on Mac OS circa 2004), I believe it is probably quicker on Linux. However, when I tested it on windows, it would take forever. It turned out I had anti-virus that hooked every file-open and scan the file for viruses before allowing the process to continue.
So, in a way, the file pool is mostly a mechanism to guard against overzealous anti-virus software that makes otherwise fast operations slow. But it probably helps keeping other system load nad resources a bit lower too.
It's also worth pointing out that just because a file is opened and closed doesn't necessarily mean the kernel force-flushes the page cache corresponding to that file immediately. You really just open and close a view into the page cache.
That said, I'm always interested in seeing measurements highlighting problems (or highlighting scenarios that are handled well for that matter).
@FranciscoPombal commented on GitHub (May 26, 2020):
@arvidn
Ok, I understand the issue more clearly now.
Still, can it not become a bottleneck at some point? If the limit is too low, won't that result in a lot of "churn" and lots of open/close syscalls, as libtorrent issues a lot of requests to open/close to keep within the limit of max simultaneously opened fds of 40? Just speculating here, I don't actually know much about the internals of the disk cache code.
I would also speculate that the reduced performance on Windows with anti-virus is not because the anti-virus makes the syscall slow per se, but that it spins a lot of CPU to "scan" what is being opened and closed, thus starving out other applications of CPU cycles.
I think this is consistent with the observation above that going from 40 to 2000 max open fds yields a substantial performance improvement, but going from 2000 to 40000 does not. My hypothesis is that from 40 to 2000 the "fd churn" dominates the cost, but from 2000+, even though that particular bottleneck is alleviated, a new one is introduced, in the form of the CPU cycles (and disk I/O) consumed by the anti-virus "scan" that now dominates the cost. Hence no change in performance from then on.
But please correct me if none of this is actually applicable, or even flat out incorrect.
IIRC one thing about Transmission that annoyed a lot of people is the hard cap on 1024 fds (not sure if that was changed with the new 3.0 version). Additionally, qBittorrent itself was recently (4.2.0) changed to set the open fd limit of the process to "unlimited" on Linux platforms - up from what mainstream distros like Ubuntu seem to use as default, which I believe is 1024 (or something in that ballpark). In the case of qBittorrent, it was causing stalled downloads and slower progress, if not even I/O errors.
@ned-martin @bksinn78 do you mind testing with anti-virus disabled (if using Windows Defender, use the group policy editor to do this) 2 times, one with file pool set to
40, another with it set to40 000?Apart from this, I guess the best way to test the "fd churn" hypothesis (if it even has any merit to start with) without other stuff interfering (inefficiencies in other parts of qBittorrent could be playing a part here) would be to load up
client_testwith a ton of torrents and files, and measure performance and number of open/close calls with the file pool set to40and40000.@arvidn commented on GitHub (May 26, 2020):
Yes, of course it can, and yes; it does cause a lot of syscalls. But if those syscalls are take virtually no time compared to, say
read()orwrite(), I wouldn't call it a bottleneck. The faster the disk I/O gets, and the more likely it is to be in the page cache (and just turn into amemcpy), the more likely everything else around it is to become bottlenecks.In my anecdote, I was making a lot of system calls to open and close files, but it wasn't a noticeable slow down. Now, keep in mind it's an anecdote and it's more than 15 years old :)
Right, scanning the whole file is also expensive, probably the most expensive part. I don't know for sure if anti-virus software does that or not, but if they would, that would most likely be the dominant cost.
In my story, it doesn't really matter what the anti-virus did though, even if they had optimized it and had made it very quick, it became unbearable when doing it for every 16 kiB chunk being accessed. Because that's very often.
I haven't read through this whole thread carefully, but that makes sense.
The file pool size limit could probably be raised quite a lot on windows with no problems. iirc, the limit on open files per process on windows is in the order of 30k.
@xavier2k6 commented on GitHub (May 26, 2020):
The default max is 512 open file descriptors I believe.
Windows have limits on the number of Open File Handles. It will be around 16,711,680 on 64 bit machines and on 32 bit machines it will be 16,744,448.
see here for reference
This is the reference Microsoft Blog Post Pushing the Limits of Windows by Mark Russinovich
Is HANDLE similar to file descriptor in Linux?
Passing FDs/handles between processes on Unix and Windows -- a comparison
This can be confirmed by
testlimit -hfromsysinternals@FranciscoPombal commented on GitHub (May 26, 2020):
@xavier2k6
It appears there is a default max of 512 and a hard cap of 2048, but that only applies for
std{in,out,err}.The max limit of open fds/handles in both Windows and Linux is in the millions, which is more than enough for us under any circumstance.
Yes. EDIT: mistook this for an actual question, sorry
@arvidn
The benefits of the file pool vs the old way are clear. However, it is possible that having the file pool value set too low hinders performance with lots of torrents/fles. In this context, it is very possible that
40is too low (at least for qBittorrent). I would imagine someone with thousands of torrents to have a total file count easily in the tens of thousands, and possibly in the hundreds of thousands. Of course it is also possible to reach a high file count in the thousands/tens of thousands with a relatvely low number (10s, 100s) of torrents, if all/most of them contain a lot of files (like 100+).That being said, should wait for more conclusive test results to know more.
@xavier2k6 commented on GitHub (May 26, 2020):
That wasn't an actual question on my part - just the name of the article in that link.
Just thinking out loud with below:
Adjusting
asychronous I/Omay also help in conjunction with increasingfile pool size?What about adjusting the
socket backlogsize? - would this have a positive or negative effect?@ned-martin commented on GitHub (May 26, 2020):
File pool size: 40: approx. 10 minutes
File pool size: 40,000: approx. 10 minutes
I tried multiple times, both with virus scanning on and off, and it makes no difference. Note that virus scanning has always excluded qBittorrent's app dir.
Times varied between 9 to 12 minutes. Confusingly, pool size also made no difference, despite making a measurable difference previously. I even rebooted the system in case something weird was going on, but the times remain pretty constant at around 10 minutes. I can't explain the previous 18 minute time with the exact same settings and version of qBittorrent.
@FranciscoPombal commented on GitHub (May 27, 2020):
@ned-martin thanks for testing. It would be nice to have more independent confirmations, but so far this means the that file pool size is not really the bottleneck here.
You could try raising Asynchronous I/O threads to 16 or even higher, but I doubt this will help with startup, unless a lot of torrents are rechecking on startup. Changing the socket backlog size shouldn't make a difference either.
@arvidn commented on GitHub (May 27, 2020):
My bet is that there's some algorithm somewhere that scans all torrents to do something, and while loading effectively turns into taking big-O n^2 complexity, which most people wouldn't notice, but with sufficiently large n it quickly becomes way too slow.
I try to test and avoid situations like this in libtorrent, but it's surprisingly easy to accidentally introduce a performance regression like this.
@FranciscoPombal in libtorrent, there's a tool called
connection-testerwhich can be used to create lots of test torrent files. I would suggest you generate 10000 test torrents and add them to qBT under a profiler.@xavier2k6 commented on GitHub (May 27, 2020):
@ned-martin Can you show the timings of the logs like https://github.com/qbittorrent/qBittorrent/issues/12914#issuecomment-634085937
@ned-martin commented on GitHub (May 27, 2020):
All the timings mentioned above were taken from the logs. I did actually record the exact times for each test, but as they varied randomly around 10 minutes (varying by over a minute but seemingly randomly - that is, the file pool didn't seem to make a difference) I just gave an average and didn't save the exact times.
Possibly also worth mentioning that I always force-quit qBittorrent, as it never actually quits as far as I can tell - maybe it will eventually, I don't know.
I tried changing the Asynchronous I/O threads to 16 and it took 9 minutes to start up. I've only tried once, but I suspect it's not measurably faster.
@bksinn78 commented on GitHub (May 27, 2020):
same issue with anti virus disabled
this is my torrent info dunno if it helps?
24.1 TB (26,569,859,328,194 bytes)
321,755 Files, 12,129 Folders
7947 total torrents
@bksinn78 commented on GitHub (May 27, 2020):
also right now i only have 2000 torrents going and it works fine with this many
I'm running a Xeon E5 2670 with 64GB of ram don't know if any of this helps
@nokti commented on GitHub (May 28, 2020):
I added more (but not necessarily helpful) info in the other thread: https://github.com/qbittorrent/qBittorrent/issues/12914#issuecomment-635184255
@ghost commented on GitHub (Jun 2, 2020):
Since OP is storing files on a network share path, maybe give this (https://github.com/qbittorrent/qBittorrent/pull/12683) a try to exclude the possibility of UNC path patch bottlenecks.
@xavier2k6 commented on GitHub (Jun 20, 2020):
Windows test build of 4.3.0(Alpha1) with listed libraries:
"Windows Test Build" download link below:
qBittorrent master +git 9dfeeb9 with Boost 1.73 + Qt 5.15 + libtorrent 1.2.7 +git 89419b1
@ned-martin commented on GitHub (Jun 22, 2020):
This took 10 minutes to load the UI, which is basically the same as the previous version I was using.
@ghost commented on GitHub (Jun 22, 2020):
^can you reproduce the same issue on qBt 4.2.1?
@ned-martin commented on GitHub (Jun 22, 2020):
4.2.1 took 5 minutes, which is still a terrible user-experience, but significantly faster than 4.2.5 or the 4.3 alphas.
In fact, it's closer to 4 minutes, if being precise:
10:16:43 - qBittorrent v4.2.1 started
10:21:00 - Python detected
@ghost commented on GitHub (Jun 22, 2020):
Since the startup time was cut in half, I think it's safe to assume that the bottleneck is where qBt parses the fastresume files and loads it into session.
The fact that 4.2.5 takes longer is it contains a patch for broken UNC paths caused by 4.2.2. This increase the I/O 2x times as you have to read the fastresume -> patch it and then write patched ones to disk.
4.2.1 is still taking longer than 4.1.x and my guess is there's some patch for converting 4.1.x fast resumes to 4.2.x styles. I could be wrong...The devs will know better.
@arvidn commented on GitHub (Jun 23, 2020):
I found that storing fastresume in a
sqlite3database significantly improved reading performance. (but this was at least 6 years ago). I was spending the majority of the time listing the directory, opening a small file, and reading it. Both the .torrent file and the resume file would cause two such open+read of small files per torrent.This was one of the reasons I added support for saving the .torrent file inside the resume data, to at least cut it down to one open+read.
In a database though, iterating over the entries is quicker because it's all contiguous in a single file and read in the optimal order, rather than alphabetical (as I believe
readdir()gives you)@FranciscoPombal commented on GitHub (Jun 23, 2020):
There's an old (and practically abandoned, unfortunately) PR exploring this: https://github.com/qbittorrent/qBittorrent/pull/10099
@xavier2k6 commented on GitHub (Jun 23, 2020):
I've recently been testing this issue with my own NAS & 10,000 test torrents - seems the issue is regarding resume(s) alright especially if qBittorrent was not closed cleanly ie still active torrents & not all completely paused when exiting.
I'm not experiencing delays of 10mins/30mins but around 5mins....... if not exited cleanly & around 2mins if opening from completely paused state.
The delay variance can solely be dependent on hardware/network setup too (cable type/switch/drives [hdd/ssd] /ram of NAS etc)
@xavier2k6 commented on GitHub (Jun 23, 2020):
Hopefully #10099 can be picked up again.
@ned-martin commented on GitHub (Jun 23, 2020):
I never close qBitTorrent cleanly (because I can't, it never exits after attempting to quit, though the UI closes) so perhaps that's an aggravating factor.
@xavier2k6 commented on GitHub (Jun 23, 2020):
That's part of the problem, yes... this would've been handy to know at the start.
qBittorrent will eventually close but it will take time on your setup. It takes about 3mins on my setup to completely disappear from taskmanager if not completely closed cleanly.
Not closing cleanly could also lead to some possible re-checking as i had pointed out before....unfortunately the logs don't show this (checking/rechecking) as far as i'm aware......
Can you "pause all torrents" & exit cleanly/waiting for it to completely disappear from taskmanager.
How long does it take to start-up now?
Do this with 4.2.1/4.2.5 & latest master build in all 3 cases. (If you can)
@xavier2k6 commented on GitHub (Jun 23, 2020):
@arvidn In relation to the excess memory usage here, I remember reading somewhere that libtorrent's algorithm for memory detection used the memory from the entire machine & may not take in to account the set amount for a virtualized system, could this be related here?
Does the algorithm take in to account the swap page too?
@xavier2k6 commented on GitHub (Jun 23, 2020):
Do we need a build with https://github.com/qbittorrent/qBittorrent/pull/12683 to confirm?? (although - I think the not exiting cleanly is the biggest factor at play here)
There's a change in libtorrent 1.2.x resume format as opposed to libtorrent 1.1.x
qBittorrent 4.1.x used libtorrent 1.1.x & qBittorrent 4.2.x uses libtorrent 1.2.x format
@ned-martin commented on GitHub (Jun 23, 2020):
No, I cannot, unfortunately. I have left it "quitting" for over 8 hours without it ever exiting. This (no clean restarts) was mentioned before but may have got lost - normally it uses up all the ram, becomes unstable, and crashes (after several hours or even days). Because this sometimes makes the system itself non-responsive, I've taken to killing the qbittorrent process once it reaches a certain amount of ram usage. It's not ideal. But as mentioned, I've left it for huge amounts of time without it ever exiting. I'll try again with this version in case it's different - starting to lose track of what versions do what.
It doesn't seem to cause any torrent re-checking (assuming you mean the re checking that I can see in the ui), though occasionally torrents are paused or go into an error state due to a filesize mismatch or unable to find file. I haven't looked into it extensively but I think this is usually the result of more than one torrent with the same name downloading and conflicting with each other and the auto-move when completed setting - it's a long-lived issue and there's a few bugs about it I've logged here in the past.
@xavier2k6 commented on GitHub (Jun 23, 2020):
(for clarity) Indeed, you have: #12842 #12872 #7982 & #11348
@ghost commented on GitHub (Jun 23, 2020):
@ned-martin
Do you happen to use https trackers?
Can you switch to http tracker in that case and see if stalled client exit issue as well as memory leaks are reproducible?
@ned-martin commented on GitHub (Jun 23, 2020):
I don't know how to do that. My understanding is that the trackers come from the torrent files and I don't have any control over them? Unless there is some quick way to change all trackers from hundreds of torrents to http or https, then I don't know how to do that sorry.
@arvidn commented on GitHub (Jun 23, 2020):
I would expect the HTTPS tracker leak is the dominant issue at this point.
No, it just looks at physical RAM. However, if you're run in a container or under
ulimit, the physical memory may not represent what's available to the process.@ned-martin commented on GitHub (Jun 23, 2020):
It's just gone 12 hours since I "closed" qbittorrent - but its process is still running. I think it's safe to say this version does not quit either. This is using the 4.3.0alpha1 from this thread.
@ned-martin commented on GitHub (Jun 23, 2020):
Perhaps slightly off-topic, but I can still see qBittorrent creating new connections, even though all torrents are paused and the application was theoretically closed. It's only creating a handful of connections. I believe they're to trackers, and most aren't getting past the SYN_SENT stage, so probably dead trackers, though some are connecting.
@ned-martin commented on GitHub (Jun 23, 2020):
I discovered something! If I pause all torrents, File -> Exit, wait a while, then force-quit the process, and then start it, but don't unpause any torrents and then quit it again, it cleanly quits the second time.
Then, when starting from a clean quit, it is significantly faster. It's still not an ideal user experience - a full minute of a white screen with the non-responsive-app thing going on, but it sure beats 10 minutes.
10:28:19 - qBittorrent v4.3.0alpha1 started
10:29:21 - Couldn't download IP geolocation database file
This doesn't really help me because I can't cleanly quit the program in normal use, meaning I can't cleanly start it in normal use... but hopefully that helps explain what's going on.
Update: I spoke too soon
Unfortunately, all this has done is transfer the UI frozen time from startup, to "resume all torrents". While the app showed a responsive UI in 1 minute, it took 10 minutes for the UI to become responsive again after unpausing all torrents.
So overall, it's taken almost exactly the same amount of time (10 to 11 minutes), starting from a clean shutdown, to get to an unpaused, torrents downloading state, just the points at which the app is frozen is a bit different. Clearly, it's the unpausing/resuming/starting torrents part that causes the greatest delay.
@nokti commented on GitHub (Jun 24, 2020):
I tried that "trick" and confirm that qBit then started and was operational in less than a minute (compared to the 4-5 minutes it usually takes).
What I usually do: File>Exit, wait for the process to disappear from the task manager, turn off computer for the night.
What I did this time: Pause all torrents, File>Exit, wait for the process to disappear from the task manager (it takes 2-3 minutes), restart qBit with all torrents still in Pause, File>Exit (process disappeared in only a few seconds), restart qBit, un-pause all torrents, within a minute I was already seeding to peers!
@xavier2k6 commented on GitHub (Jun 24, 2020):
I pointed this out to you previously https://github.com/qbittorrent/qBittorrent/issues/12825#issuecomment-648046039
ALSO: @ned-martin Can you please stop editing your posts & changing the walls of text, if you need to change something just use strikethrough.
It's very hard to follow your posts at times/when reviewing this case on numerous occasions.
If it's hanging/freezing while resuming your torrents, it may be best to tweak your settings to see what is a better fit for your system.
You should probably get in to the habit of pausing all torrents/wait for all activity to finish (no downloading/uploading etc.) & then exiting qBittorrent.
The delay in the process disappearing from taskmanager completely is from updating the
fastresumefiles - if you exit cleanly following what I've just said in my previous sentence otherwise the delay will be from the updating thefastresumefiles & reading/writing torrent data to/from disks.2 Points to take note of from this situation:
qBittorrent should probably implement an automatic feature of
PAUSE ALL TORRENTSwhen exiting & it will alleviate some of the reports of slow start/slow close.qBittorrent needs to implement #10099 or equivalent ASAP now that libtorrent 1.2.x has been released & implemented.
@ned-martin commented on GitHub (Jun 24, 2020):
Yes, that's why I started testing it.
Sure, I'll post new posts with updates instead of editing existing ones. I try to only edit existing ones within a few minutes of creating them, but happy to not do that.
Happy to try any tweaking people may suggest. So far nothing anyone has suggested has made any useful difference.
I think you may have missed some things:
And lastly, sorry if this is hard to follow or is annoying. I'm just trying to help make the program better. Despite the hassle, I'm managing to use it ok myself and am appreciative that others have written it so that I can use it.
@xavier2k6 commented on GitHub (Jun 24, 2020):
You could make use of the categories section to make it easier for resuming torrents etc.
(My
long haulcategory are torrents that I will always resume)The memory ramping up could be from a possible
https trackerleak or how this type of tracker is being handled bylibtorrent/qBittorrentthis is still an on-going investigation/WIP.I also note that you haven't enabled memory compression from what I could see in your pics from previous posts so unsure if that may or may not help for your case.
Have you also tried adjusting your send/receive buffers on the network card?
Are jumbo frames enabled/disabled on network card/nas?
Another thing that qBittorrent could do in future or at least look into is the use of
segment heaplikemicrosoft edge&chromeare using/implementing from windows 20H1 (This is me only thinking out loud)@ned-martin I'm not giving out to you & apologies if my posts are coming across as harsh etc. it's just that sometimes when reviewing this & in the middle of quoting you/pointing out certain observations - the post is edited & I have to re-write what I was about to say or completely abandon what I was going to write because the context has so dynamically changed.
Can you post your config file from
%USERPROFILE%\AppData\Roaming\qBittorrent? (Redact any IP address/private info etc.)@ned-martin commented on GitHub (Jun 24, 2020):
Attached is the config file: qBittorrent.ini.txt
Note that I went through this before, and changed many values to do with caching and so forth.
@xavier2k6 commented on GitHub (Jun 24, 2020):
Seems to be alot of settings in relation to your bittorrent session missing from the config file?
These are just a few:
OSMemoryPriorityCheckingMemUsageSizeSendBufferWatermarkSendBufferLowWatermarkSendBufferWatermarkFactorAlso, where you save your logs isn't the default location but appears to be saving to the NAS?
JUST SPOTTED: You are connecting/running qBittorrent through
WEBUICorrect?@ned-martin commented on GitHub (Jun 24, 2020):
Can't help you there. That's a copy/paste of the config file, with some values removed (indicated by <removed>). The things you've mentioned do not appear in my config file.
That's correct. I save all data to the NAS (apart from the config file and the fastresume files and stuff - though if I could figure out how to convert an existing install to a portable install, I'd probably save that there too)
No. I believe I set up the webui once to check it out years ago, but I never use it.
@xavier2k6 commented on GitHub (Jun 24, 2020):
Ya, they only seem to appear in the config file If changed from defaults......too late & too tired to be looking at this now.....going blurry eyed.
Will have another look again tomorrow, maybe someone else may pick up on something else in the meantime.
@ghost commented on GitHub (Jun 27, 2020):
Yes maybe?
If not exiting cleanly is the main factor...then qbt 4.2.1 exits cleanly and 4.2.5/4.3.0 doesn't?
@ned-martin commented on GitHub (Jun 29, 2020):
Based on my testing, exiting cleanly doesn't make a big difference to the time the UI is frozen, it just varies the way it's frozen.
I performed some tests today and yesterday (note that I've deleted some torrents so these aren't necessarily comparable to previous tests, sorry)
[a] I go File -> Exit, wait a while, then force quit the process.
[b] Sometimes if I "quit" (file -> exit, wait a while, then force quit) with torrents paused, when I re-open qBt, it opens with torrents not paused. It's like the force-quit part is causing it to not save its settings sometimes. In this case it behaves the same as 1 above.
[c] The only way I can exit cleanly is to pause all torrents, force quit, re-open, and then exit without ever un-pausing any torrents.
It would appear that torrents being paused is the significant factor, not the clean exit. The time delay appears to be from resuming torrents - be they paused, or from startup.
@ghost commented on GitHub (Jun 30, 2020):
^ then I would assume the UNC patch is causing a 2x delay. Maybe @xavier2k6 can provide a build to confirm that.
@xavier2k6 commented on GitHub (Jun 30, 2020):
I could provide a build but it would probably be quicker to just revert to 4.2.1 to test as that doesn't have the UNC patch.....
@ned-martin another thing to do would be to change your
save resume intervalfromcurrent settingof5to30, this may hopefully alleviate some of the delay as well.Do you also have any
networked drivesthat are no longer in use? - recently qBittorrent was freezing/hanging for a small period of time especially when opening theoptions tab(removed the network drives no longer in use & all was good again)You can probably lower the
file pool sizeagain back to say maybe4000from the40000@arvidn commented on GitHub (Jun 30, 2020):
I think the proper way to diagnose these hangs is to make a build with debug symbols (but still a release build). Whenever there is a hang, go to TaskManager, right click on the process and take a stack trace (I forget the details of what that's called). two or three such stack traces during a hang would be really helpful in understanding where the bottleneck is.
Presumably qBT is performing a blocking call somewhere in the UI thread. Stack traces like this would pin-point which call is being made and where.
@xavier2k6 commented on GitHub (Jul 1, 2020):
qBittorrent already includes these?! (It generates a
pdbfile anyway)Create a dump file?
@FranciscoPombal commented on GitHub (Jul 1, 2020):
I take it means CMake's
RelWithDebInfobuild type or equivalent.Debugmight be a tad too slow (but note that at least in CMake,NDEBUGis still defined by default, so it wouldn't be excessively slow due to all the very expensive assertions in libtorrent).@lucky1luc commented on GitHub (Jul 4, 2020):
I had the same problem until I switched off the 'announce' in the advanced section.
Load time dropped to 10 seconds. Apparently using a VPN with 4.2.5 is deadly on performance if it has to wait for announcing to all trackers. 4.2.1 does not have this behavior.
@ned-martin commented on GitHub (Jul 6, 2020):
You are right. With those turned off my UI load time goes from approx 10 minutes to approx 2 minutes.
What's the effect of leaving those options off? They sound important and useful.
@FranciscoPombal commented on GitHub (Jul 6, 2020):
This is strange, as it suggests something about these operations is blocking the main/GUI thread, but it definitely shouldn't. CC @glassez @Chocobo1.
@lucky1luc commented on GitHub (Jul 22, 2020):
it is deinitely the "Always announce to all trackers in a tier" setting that causes the problem. The "all tiers" setting can be switched on without any performance hit.
@glassez commented on GitHub (Jul 24, 2020):
The announcing itself works in a different thread, so it should not affect the GUI. However, I assume it can generate a lot of alerts, the processing of which may be the cause of this problem.
@Chocobo1, what do you think?
@arvidn commented on GitHub (Jul 24, 2020):
@lucky1luc when this happens; is the GUI frozen? i.e. it doesn't respond to any interaction, or is the window not even showing?
more importantly, is the qbittorrent process using near 100% CPU? (by which I mean one full CPU core, I believe windows reports CPU usage as fraction of all CPU cores on the machine)
@ned-martin commented on GitHub (Jul 24, 2020):
For me, with announce to all turned on, from opening, I get the ui showing after maybe a minute or so (never timed that part but it is exceptionally slow), then it's frozen - as in, it's white, has the basic window chrome drawn but no ui controls drawn, no list etc.- totally non-responsive, for another up to 10 minutes.
With it turned off, same process but times reduce down to only a few minutes.
It doesn't seem to hit the maximum on any single core while frozen, but I'm running it on a virtualised platform so I'm a bit dubious about the measurements - it does seem to be very coincidentally close to 25% cpu use across 4 "virtual" cores, but no single core is ever close to 100%... so as far as I can tell it's not cpu bound but the 25% use makes me suspicious so if you know a better way to measure this I'm happy to do some tests.
@Chocobo1 commented on GitHub (Jul 24, 2020):
I'm not sure, without actual proof of too many alerts I'm inclined to think the problem lies elsewhere.
@lucky1luc commented on GitHub (Jul 24, 2020):
I have just switched the 2 "all trackers and all tiers" back on and report following:
The GUI is not completely frozen. The splash screen stays for a long time. if I click on the icon in the taskbar after a couple of minutes, it shows a screen, completely black with "not responding" on the title bar After 10 minutes the screen turns white (so there is some GUI activity, albeit very slow). After 21 minutes my torrents show up on the screen.
When Qbittorrent is started CPU usage goes up a little (to 23-25%), but not extreme. Task manager shows "not responding" as well, and power consumption "Very High". My windows/PC is not blocked, just the qbittorrent process is not responding for +/- 20/25 minutes. some days it is faster (today 21 min) some days it is slower, which made me think of a networking problem in the first place - too many trackers to contact. That is why I swiitched off the all trackers and all tiers, and it started in 15 seconds after that.
I have 300+ torrents, and for a while I added a lot of trackers to each torrent, because my DHT nodes were not going up. I am behind a VPN (PIA) which has caused me a lot of problems connecting for a while, but now seems stable. I am now trying to remove a lot of these unnecessary trackers again, but this is not a very well implemented in qbittorrent (I mean management/removal of Trackers from torrents). I am forced to go to each torrent separately and remove the trackers.
I could use procmon (sysinternals tool) to make a log, but then I will want to anonymize the logs first - also not a task to do in a short time.
Hope this helps. Regards
Luc
@lucky1luc commented on GitHub (Jul 24, 2020):
one extra thought. This behaviour changed after 4.2.1 I reverted back to 4.2.1 and it also works in the 'fast way' regardless of the 2 settings. now i am on 4.2.5 and I will stay there with the all trackers setting turned off.
@ned-martin commented on GitHub (Jul 24, 2020):
I think that means the UI thread is completely non-responsive - I believe Windows applies a white overlay when it detects a UI is non-interactive, nothing to do with qBT specifically.
I'm on 4.3.0alpha1 so it's not fixed here yet.
I also have many trackers added to many torrents, many of which are old and dead, but as you say there doesn't seem to be any way to easily manage or remove them.
@arvidn commented on GitHub (Jul 25, 2020):
the libtorrent logic for picking which tracker to announce to is hairy and error prone. My bet is that the libtorrent thread is busy iterating over trackers and issuing tracker announces, and the reason the GUI is affected is because it makes a blocking call into libtorrent, so it's stalled waiting for the libtorrent thread to become available.
@jagannatharjun commented on GitHub (Jul 31, 2020):
@xavier2k6 @an0n666 really appreciate your work on trying to find the source of bug, just out of curiosity why didn't you considered a profiler, there is this a very easy to use profiler https://github.com/google/orbit , also if you can compile with mingw, you can use gprof, which will provide a lot more details, with no extra software needed at all (it just links with your application and provide a perf stat on application exit).
@ghost commented on GitHub (Jul 31, 2020):
Actually there was a bug in libtorrent due to which those two settings were not respected. I reported this issue to @arvidn back in February (https://github.com/arvidn/libtorrent/issues/4302) and he patched it. qBit 4.2.1 is affected by this bug.
When I was testing qBit master with the patched libtorrent before 4.2.2 release, I myself experienced this GUI locking issue. But I thought it’s a qBit bug as qBt had many changes in between 4.2.1 and 4.2.2 and thus I overlooked the issue. Also it happened pretty rarely for me and was not reproducible.
@arvidn commented on GitHub (Jul 31, 2020):
people experiencing this, how many tracker announces are you triggering on startup, roughly?
i.e. i.e you have
announce_to_all_trackersandannounce_to_all_tiersboth set to true, every tracker in every started torrent will be announced to.So, of the torrents that are started on startup, how many tracker entries to they all have combined? i.e. the sum of all the number of trackers.
If this is a very large number, it could simply be explained by scalability in a large number of trackers per torrents has not really been considered and optimized.
I would question the utility of such optimization over simply setting a limit on the number of trackers allowed per torrent. Does anyone who adds a large number of trackers to torrents have any evidence to suggest it improves anything?
@arvidn commented on GitHub (Jul 31, 2020):
Obviously I'm open to the possibility that there is a performance issue in libtorrent even for "normal" numbers of trackers. It would be great if someone that can reproduce this could provide some more details on the specific conditions it happens under.
e.g. Do the trackers need to work? or do they need to be down?
do they need to be HTTP, HTTPS or UDP?
Do they need to all be in the same tier? or do the need to be in separate tiers?
@ghost commented on GitHub (Jul 31, 2020):
If libtorrent waits for all endpoints to fail to go to the next tracker, I would consider that be the correct behaviour.
However qBit doing a blocking call to check for tracker status seem like an actual issue here.
I think qBit waits for all trackers to spit out something before it loads the GUI.
@ghost commented on GitHub (Jul 31, 2020):
I always thought they slow down your codes even more and never bothered to go down that road.
@FranciscoPombal commented on GitHub (Jul 31, 2020):
@arvidn
I suspect many people add trackers from lists such as this one: https://newtrackon.com/list to some/all their public torrents, to increase the chance of finding peers (or at least finding them faster) for low-health torrents.
I also sometimes do this, though I have no real hard evidence concerning the effectiveness of this (e.g., actually observing whether such blanket lists of trackers are strictly necessary to find peers to finish certain torrents, and how often this is the case).
This can mean a lot of tracker connections per torrent. At ~140 trackers per torrent, one can easily reach > 100 k tracker connections with less than 1000 torrents. So scalability of tracker announces is important in this case.
Either that or a possible alert-processing bottleneck (i.e., announcing to so many trackers generates so many alerts that qBittorrent spends basically all the time processing them)?
@ghost commented on GitHub (Jul 31, 2020):
My apologies. I re-read https://github.com/qbittorrent/qBittorrent/issues/12825#issuecomment-662562087 this comment. I think this can indeed generate lots of alerts. But 4.2.1 also announced to all trackers in a tier due to the libtorrent bug and it was unaffected.
@arvidn commented on GitHub (Jul 31, 2020):
It seems quite unlikely that there would be a useful peer on some tracker not associated with the original .torrent file, and that's also not on the DHT. Based on my speculation that is, I have not investigated this.
@ghost commented on GitHub (Jul 31, 2020):
This logic would only apply when the always announce to all trackers in a tier is set to false. But the users are experiencing it with that set to true. Meaning when libtorrent doesn’t check which trackers to announce to next and just announces to every tracker simultaneously.
@arvidn commented on GitHub (Jul 31, 2020):
Heh, I remember the days when trackers were having performance problems accepting peers fast enough over HTTP (leading to UDP trackers). I wasn't imagining clients would have this problem :). I would expect UDP trackers would help to the same extent.
@arvidn commented on GitHub (Jul 31, 2020):
Not really. fundamentally the libtorrent tracker logic still has roots in the original spec where there's never more than one tracker. And when it's time to announce to the tracker, libtorrent has a loop over all trackers and tries to figure out which ones to announce to. This loop is hairy because it handles:
There have been bugs in the past where this loop would get stuck, spinning indefinitely (because of subtle completion conditions).
@xavier2k6 commented on GitHub (Jul 31, 2020):
I did think about a
profilerbut I'm not really experiencing the issue, have been slightly able to reproduce part of the issue....but OP has multiple issues besides the slow loading of theUI& unfortunately I don't have the time to fully go through & contribute to this right now.@ghost commented on GitHub (Aug 1, 2020):
I managed to reproduce the client exit stalling with 1k torrents each having 10 non working trackers.
The stall happens with all combinations of announce to all tiers & announce to all trackers.
The client will probably eventually exit...I checked with wireshark and there were active tracker announces.
@arvidn commented on GitHub (Aug 2, 2020):
@an0n666 can you describe the trackers you use in your test in more detail?
Did you generate the torrents?
Do all trackers have different hostnames? (i.e. each individually will require a hostname lookup)
You say the trackers are non-working, is it the hostname lookup that will fail, the TCP connection to them or will they respond with a failure?
are the 10 trackers in the same tier or in separate tiers on the torrents?
I think the best way to understand what's going on is to build libtorrent with
asio-debugging=onand run from a terminal. I will do that, but I would like to replicate your test.@ghost commented on GitHub (Aug 2, 2020):
Used 1k generated torrents from here
https://github.com/qbittorrent/qBittorrent/pull/12683#issuecomment-643332845
Changed the trackers.
Added 10 example URLs.
http://example1.com/announce
Up until example10.com/announce
Some of them return 404.
Some maybe fails lookup.
All trackers were added in same tier.
@arvidn commented on GitHub (Aug 2, 2020):
as far as I can tell, the reason this is taking so long is because of the tracker queue, introduced here.
This makes libtorrent announce to 50 trackers at a time (technically, with no more than 50 outstanding announces at any given time).
Announcing to 1000 (or 10000) trackers 50 at a time will take a while.
@ghost commented on GitHub (Aug 2, 2020):
My UI didn’t take much time to load though. However I experienced lots of GUI lockups whenever I was in transfer tab of qBit. This gives me a feeling that it’s purely GUI locking issue and not due to alerts or anything else.
@ghost commented on GitHub (Aug 2, 2020):
If all these trackers are in not working state. I.e they failed to respond properly during event=started, an event=stopped announce should never be initiated.
Edit: maybe it was stuck in the event=started announce queue when I exited qbt.
@ghost commented on GitHub (Aug 2, 2020):
Anyways I think it’s not a real life scenario where you’ll have 10k non working trackers to deal with during client exit(unless of course your connection breaks during the exit process).
@xavier2k6 commented on GitHub (Aug 2, 2020):
That patch isn't apart of qBittorrent 4.2.5 as that was released in April whereas that patch was merged in May, it would however be included in any recent qBittorrent
masterbuild.@arvidn commented on GitHub (Aug 2, 2020):
you're right. The trackers I was waiting for on shutdown had been queued up for their initial announce. I think there's an improvement to be made here by cancelling the tracker announce queue on shutdown.
If I pause the session, and wait 5 minutes, then shutdown is quick.
looking into this some more, I found an oversight in my original queued-tracker patch from 3 months ago. Here's a fix:
https://github.com/arvidn/libtorrent/pull/4934
Please test it!
@ghost commented on GitHub (Aug 2, 2020):
@xavier2k6 I was testing with the latest libtorrent so queue applied to me. It was the initial announce queue that was causing the client to stall and not the stop announce.
@xavier2k6 commented on GitHub (Aug 2, 2020):
@arvidn Can you review command below:b2 -q --without-python --toolset=msvc-14.2 address-model=64 variant=release link=static runtime-link=static debug-symbols=on encryption=on crypto=openssl openssl-version=1.1 asio-debugging=on logging=on dht=on windows-version=win7 boost-link=static -sBOOST_ROOT="C:\QBITTORRENT\boost_1_73_0" include="C:\QBITTORRENT\install_msvc64\base\include" include="C:\QBITTORRENT\boost_1_73_0" library-path="C:\QBITTORRENT\install_msvc64\base\lib" library-path="C:\QBITTORRENT\boost_1_73_0\stage\lib" --prefix="C:\QBITTORRENT\install_msvc64\base" cxxflags="-O2 -Gw -GL" define=BOOST_ASIO_DISABLE_CONNECTEX linkflags="/NOLOGO /DYNAMICBASE /NXCOMPAT /LTCG /OPT:REF /OPT:ICF=5 /MANIFEST:EMBED /INCREMENTAL:NO" --hash -j 8If it looks ok to you - then I will compile 2x windows build using that command:1. with latest qBittorrent master & https://github.com/arvidn/libtorrent/pull/4934#2. with qBittorrent (Revert broken UNC paths patch) https://github.com/qbittorrent/qBittorrent/pull/12683 & https://github.com/arvidn/libtorrent/pull/4934EDIT: - Not an option as per https://github.com/qbittorrent/qBittorrent/issues/12825#issuecomment-667679733
@ghost commented on GitHub (Aug 2, 2020):
^you cant run qbt from a terminal on windows. Asio debugging won’t help if u can’t print to console.
@xavier2k6 commented on GitHub (Aug 2, 2020):
ah, well - that's fair enough, thanks for the calrification.
@jagannatharjun commented on GitHub (Aug 2, 2020):
if you're building with qmake config like
qmake "CONFIG += console"if building with cmake change this to
github.com/qbittorrent/qBittorrent@fd200ac31d/src/app/CMakeLists.txt (L93)False
@xavier2k6 commented on GitHub (Aug 2, 2020):
@jagannatharjun building with MSVC 2019......so cmake..... is command https://github.com/qbittorrent/qBittorrent/issues/12825#issuecomment-667679060 ok to use along with modifiying the
Cmakelistsfile?So building windows build "IS" possible with asio-debugging=on??
@jagannatharjun commented on GitHub (Aug 2, 2020):
yes, I don't see it affecting anything, I use it all time when working with qbittorrent.
@xavier2k6 commented on GitHub (Aug 2, 2020):
Great, does it output to the logs or???
@jagannatharjun commented on GitHub (Aug 2, 2020):
I don't know about asio debugging stuff but with these changes it will print everything to console written to stdio and stderr
@xavier2k6 commented on GitHub (Aug 2, 2020):
@jagannatharjun ok, thanks - I'm putting any intended release of builds on hold as may have discovered a possible bug/regression of torrent rechecking loop with latest master qBittorrent & libtorrent. 👎
@arvidn commented on GitHub (Aug 2, 2020):
@xavier2k6 oh, should I hold off libtorrent-1.2.8?
some comments on your command line:
include="C:\QBITTORRENT\boost_1_73_0"andlibrary-path="C:\QBITTORRENT\boost_1_73_0\stage\lib". Neither of those should be necessary. Since you setBOOST_ROOT, boost should be built and linked as part of the b2 build, and it should figure out where the headers and the build output is. If the build fails if you remove those, something fishy is going on. Perhaps settingBOOST_ROOTlike that isn't working in that case.--toolset=msvc-14.2, I'm a bit surprised to see this work with the--flag prefix. You can just saytoolset=msvc-14.2, or actually, justmsvc-14.2.@ghost commented on GitHub (Aug 2, 2020):
@arvidn
Read https://github.com/qbittorrent/qBittorrent/pull/13206#issuecomment-667685392 and onwards
@xavier2k6 commented on GitHub (Aug 2, 2020):
^
&
I need to do more testing but anything added into qbittorrent now e.g. (from 2.8.'20) will complete 100% & will not need to be rechecked after restart.
Any torrent 100% completed before now will need to be rechecked after every restart due to file size mismatch.
(it will always go back to 100% after rechecking or forced recheck but will still fail withfile size mismatch on startup)
so, seems any pre-existing completed torrents will be re-checked & if starting from scratch....won't need to be.
regarding the toolset commands -> they are mostly from the official way qBittorrent is compiled via the wiki page that @sledgehammer999 uses for official builds?!
@arvidn commented on GitHub (Aug 3, 2020):
@xavier2k6 the only recent change in this logic (that I can think of) was related to the seed-mode flag. Are any of your torrents added in seed-mode?
@xavier2k6 commented on GitHub (Aug 3, 2020):
they weren't added in seed mode, had been added as normal torrents back in 2019 - only downloaded/completed recently........so would only have been seeding for a small period of time then.
have force rechecked my torrents on a few occasions in the past without issue.......problem may actually be a qBittorrent commit in master anyway & not libtorrent, see #13206
In any case, I will take a bit of time & look in to this more on my end & open a new issue in the relevant faulting repo when necessary as to not divert away from the issue in this thread & #13206
@xavier2k6 commented on GitHub (Aug 3, 2020):
@arvidn feel free to release 1.2.8 if you want...
@ghost commented on GitHub (Aug 3, 2020):
The delayed exit issue seem to have been fixed now for the initial queue case.
However I went ahead and added 6 working trackers to 1000 torrents, waited for them to finish the initial announce and then exited the client. It took around a minute to exit.
I don't know if that's too long, but some people might just force close the app when they're shutting down their PC.
So wouldn't it be better to exclude stop events from the queue to facilitate a faster client exit? As I suppose all of them will succeed/timeout within 5 seconds(stop_tracker_timeout) and the client will exit faster. Unless libtorrent still loops around all trackers and allowing each one 5 seconds to timeout before moving onto the next one. I think this logic should at least not apply to stop events.
The use cases are, announcing to all tiers/trackers in a tier with lots of torrents and lots of tracker.
Or when all of your announces succeed in the start announce, but your connection is lost when you're trying to shutdown the client. So all the announces will be waiting in queue for longer due to each taking at least 5 seconds to timeout.
@ghost commented on GitHub (Aug 4, 2020):
I managed to reproduce the GUI locking issue on qBit 4.2.5 with 1000 torrents, 10 Non working trackers. The issue is 100% reproducible with every start of client.
I saw high CPU usage (25-30%) when the lock happened and memory kept going high like a memory leak. Memory usage returned to normal after the lock ended. Although It kept locking up randomly whenever I tried to click on a torrent.
I also tested a newer build which uses queue announce and I couldn't reproduce the issue. Maybe it's fixed now?
@xavier2k6
Can you provide a windows build with latest RC_1_2 and latest qBt master for @ned-martin to test and confirm?
@xavier2k6 commented on GitHub (Aug 4, 2020):
Will do.
If that's with windows - there's been a freezing issue for the last 2 months or so........affecting steam too among other things....(network shares)
@xavier2k6 commented on GitHub (Aug 4, 2020):
@arvidn @an0n666 unfortuantely, I am still experiencing the recheck loop on completed torrents (had 4 completed, now at 7) ranging in size from 15+GiB to 80+GiB with:
I uploaded the build previously to this thread but deleted the post as i didn't want it to have a adversely negative impact.
There's a regression somewhere that needs investigating more alright, but this isn't the issue thread to do so, will open a new issue & ping the two of you.
@glassez commented on GitHub (Aug 4, 2020):
Since it's probably qBittorrent own issue please ping me too.
@ghost commented on GitHub (Aug 5, 2020):
@xavier2k6
Now that the recheck loop issue has been resolved, can you please provide a test build?
@xavier2k6 commented on GitHub (Aug 6, 2020):
@ned-martin can you please try below:
Windows test build of 4.3.0(Alpha1) with listed libraries:
Download Link
@ned-martin commented on GitHub (Aug 7, 2020):
What specifically do you want me to try/test?
With "always announce to all trackers in a tier" disabled this version took 1m12s before the frozen white UI becomes responsive and the program works as expected. This is about the same as the previous version, maybe a bit faster but it varied a bit between tests in the past, so I'd say overall no improvement here.
With "always announce to all trackers in a tier" enabled this version took 2m56s before the frozen white UI is replaced with the proper UI, which is a lot faster, however the UI then remains mostly non-responsive for another few minutes - total 6m4s until the program is responsive and working as expected (approx., there's nothing logged when it becomes responsive, so I'm testing by moving the mouse around waiting until the hover effect starts working and I can click on or select anything). This is similar to starting the previous version with all torrents paused, then un-pausing them. This is a better UI experience as at least it's apparent something is happening (it's not just a white screen), and I think it's a bit faster overall than the previous version (I was getting 8 minutes frozen with it, but it did vary a bit) but it's still not a usable program for over 6 minutes.
Exiting the program took approx. 3 minutes. This is still very slow, but is a huge improvement (the program did not cleanly exit after 12 hours of waiting with the previous version)
@ghost commented on GitHub (Aug 7, 2020):
There’s usually a lot of alerts generated at startup.
If you couple that with lots of tracker failure alerts generated from each endpoint, it can actually cause locking issues due to qBt processing all those alerts.
The improvement you’re seeing is basically due to queued announces..less alerts are being generated at a time.
If qBt exposed the queue limits in its settings you could try with even lower limits.
You can also specify your network interface in qBt settings instead of listening on all interfaces. This will reduce the number of alerts generated equivalent to 4.1.x series.
@xavier2k6 commented on GitHub (Aug 7, 2020):
@ned-martin This would be a good option to try out if you can/haven't it already set.
@ned-martin commented on GitHub (Aug 10, 2020):
After running for around 4 days, the memory usage was still below 1GB. This is a huge improvement.
I then changed it to listen on only the VPN interface.
It took 2m50s to exit.
It took 2m41s to start up (go from white frozen UI to responsive UI)
It's then high-cpu-usage and the UI is "choppy" - however it's usable - the freeze-ups are less than a second long, and seem to be less frequent than before, and after a few minutes the CPU usage is still high but the UI seems to be fine.
Note that I have nothing actually downloading at the moment, so I'm unsure if that makes a difference to the tests. Torrents are seeding however.
@FranciscoPombal commented on GitHub (Aug 29, 2020):
@ned-martin Thank you for your feedback and your patience. I created https://github.com/qbittorrent/qBittorrent/issues/13304 as a follow-up. 3 minutes is clearly still too much for startup, and the UI shouldn't freeze up like that.