starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

qBittorrent slow shutdown with many torrents #7544

New issue

Closed

opened 2026-02-21 19:02:03 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-21 19:02:03 -05:00

Owner

Originally created by @sandersaares on GitHub (Jul 27, 2018).

qBittorrent version and Operating System

4.1.1 x64 on Windows 10

What is the problem

After File->Exit, qbittorrent.exe remains in the background for 5-10 minutes. This causes inconvenient delays during system shutdown.

What is the expected behavior

Fast shutdown (on the range of 10 seconds).

Steps to reproduce

Have many active torrents (e.g. seeding approx 200, totaling some 10 TB)
File->Exit
Observe that qbittorrent.exe remains active in task manager for some minutes.
Observe that if you do Start->Restart then Windows says that qBittorrent is still saving torrent progress.

Extra info(if any)

During this "shutting down" phase, the only resource usage visible is 1 CPU core that is fully utilized by the following thread:

ntdll.dll!RtlFreeAnsiString+0x1f2d
ntdll.dll!RtlFreeAnsiString+0x1b7c
ntdll.dll!RtlFreeAnsiString+0x1495
ntdll.dll!RtlReAllocateHeap+0x21d5
ntdll.dll!RtlFreeHeap+0x3fc
qbittorrent.exe+0xccef7c
qbittorrent.exe+0xcc342e
qbittorrent.exe+0x41178f
qbittorrent.exe+0x4114b4
qbittorrent.exe+0x413173
qbittorrent.exe+0x4132d2
qbittorrent.exe+0x3abde9
qbittorrent.exe+0x3abf36
qbittorrent.exe+0x3b04e1
qbittorrent.exe+0x3ac615
qbittorrent.exe+0x3b21ab
qbittorrent.exe+0x3b38df
qbittorrent.exe+0x2ca21c
qbittorrent.exe+0xcbc264
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

There is no significant disk activity. RAM usage gradually declines to zero. The screenshot below is typical of this shutdown period.

I am unfamiliar with the internals of how the code works but spending minutes reallocating memory during shutdown implies to me that there is room for algorithmic optimization here.

Originally created by @sandersaares on GitHub (Jul 27, 2018). ### qBittorrent version and Operating System 4.1.1 x64 on Windows 10 ### What is the problem After File->Exit, qbittorrent.exe remains in the background for 5-10 minutes. This causes inconvenient delays during system shutdown. ### What is the expected behavior Fast shutdown (on the range of 10 seconds). ### Steps to reproduce 1. Have many active torrents (e.g. seeding approx 200, totaling some 10 TB) 1. File->Exit 1. Observe that qbittorrent.exe remains active in task manager for some minutes. 1. Observe that if you do Start->Restart then Windows says that qBittorrent is still saving torrent progress. ### Extra info(if any) During this "shutting down" phase, the only resource usage visible is 1 CPU core that is fully utilized by the following thread: ``` ntdll.dll!RtlFreeAnsiString+0x1f2d ntdll.dll!RtlFreeAnsiString+0x1b7c ntdll.dll!RtlFreeAnsiString+0x1495 ntdll.dll!RtlReAllocateHeap+0x21d5 ntdll.dll!RtlFreeHeap+0x3fc qbittorrent.exe+0xccef7c qbittorrent.exe+0xcc342e qbittorrent.exe+0x41178f qbittorrent.exe+0x4114b4 qbittorrent.exe+0x413173 qbittorrent.exe+0x4132d2 qbittorrent.exe+0x3abde9 qbittorrent.exe+0x3abf36 qbittorrent.exe+0x3b04e1 qbittorrent.exe+0x3ac615 qbittorrent.exe+0x3b21ab qbittorrent.exe+0x3b38df qbittorrent.exe+0x2ca21c qbittorrent.exe+0xcbc264 KERNEL32.DLL!BaseThreadInitThunk+0x14 ntdll.dll!RtlUserThreadStart+0x21 ``` There is no significant disk activity. RAM usage gradually declines to zero. The screenshot below is typical of this shutdown period. ![image](https://user-images.githubusercontent.com/9914262/43340298-8a8dbd88-91e4-11e8-8347-64df4ba984f4.png) I am unfamiliar with the internals of how the code works but spending minutes reallocating memory during shutdown implies to me that there is room for algorithmic optimization here.

deekerman

2026-02-21 19:02:03 -05:00

closed this issue
added the
Performance
label

deekerman commented

2026-02-21 19:02:09 -05:00

Author

Owner

@slrslr commented on GitHub (Jul 28, 2018):

Yes, same happen to me on Windows 10, i think this is common issue, already described here: #5097
But i got used to this issue. Once, i have seen that when i disconnected internet, the process immediately disappeared, not sure if it was coincidence but think someone was saying it has to do with active internet connections.

@slrslr commented on GitHub (Jul 28, 2018): Yes, same happen to me on Windows 10, i think this is common issue, already described here: #5097 But i got used to this issue. Once, i have seen that when i disconnected internet, the process immediately disappeared, not sure if it was coincidence but think someone was saying it has to do with active internet connections.

deekerman commented

2026-02-21 19:02:10 -05:00

Author

Owner

@bathrobehero commented on GitHub (Aug 1, 2018):

Same for me, Windows 8.1 x64 but it doesn't terminates the process even after hours or days. Only "I/O other bytes" increases slowly in task manager.

@bathrobehero commented on GitHub (Aug 1, 2018): Same for me, Windows 8.1 x64 but it doesn't terminates the process even after hours or days. Only "I/O other bytes" increases slowly in task manager.

deekerman commented

2026-02-21 19:02:10 -05:00

Author

Owner

@Cpucino commented on GitHub (Aug 4, 2018):

Same problem here under Windows 7 x64. Locks all open applications, usually have to disconnect power to shut down.

@Cpucino commented on GitHub (Aug 4, 2018): Same problem here under Windows 7 x64. Locks all open applications, usually have to disconnect power to shut down.

deekerman commented

2026-02-21 19:02:10 -05:00

Author

Owner

@sandersaares commented on GitHub (Aug 21, 2018):

Issue also reproduces if I just pause all the torrents instead of File->Exit.

@sandersaares commented on GitHub (Aug 21, 2018): Issue also reproduces if I just pause all the torrents instead of File->Exit.

deekerman commented

2026-02-21 19:02:10 -05:00

Author

Owner

@sandersaares commented on GitHub (Nov 18, 2018):

During the "hang", libtorrent is doing this:

[00000196827FFFA0] block_cache mark-for-deletion piece: 2025
[00000196827FFFA0] block_cache mark-for-deletion piece: 13084
[00000196827FFFA0] block_cache mark-for-deletion piece: 5529
[00000196827FFFA0] block_cache mark-for-deletion piece: 1624
[00000196827FFFA0] block_cache mark-for-deletion piece: 12604
[00000196827FFFA0] block_cache mark-for-deletion piece: 13225
[00000196827FFFA0] block_cache mark-for-deletion piece: 5404
[00000196827FFFA0] block_cache mark-for-deletion piece: 15711
[00000196827FFFA0] block_cache mark-for-deletion piece: 12521
[00000196827FFFA0] block_cache mark-for-deletion piece: 4710
[00000196827FFFA0] block_cache mark-for-deletion piece: 111
[00000196827FFFA0] block_cache mark-for-deletion piece: 9382
[00000196827FFFA0] block_cache mark-for-deletion piece: 5358
[00000196827FFFA0] block_cache mark-for-deletion piece: 8263
[00000196827FFFA0] block_cache mark-for-deletion piece: 2728
[00000196827FFFA0] block_cache mark-for-deletion piece: 7009
[00000196827FFFA0] block_cache mark-for-deletion piece: 1266
[00000196827FFFA0] block_cache mark-for-deletion piece: 4868
[00000196827FFFA0] block_cache mark-for-deletion piece: 6882
[00000196827FFFA0] block_cache mark-for-deletion piece: 4835
[00000196827FFFA0] block_cache mark-for-deletion piece: 5599
[00000196827FFFA0] block_cache mark-for-deletion piece: 10084
[00000196827FFFA0] block_cache mark-for-deletion piece: 1119
[00000196827FFFA0] block_cache mark-for-deletion piece: 12300
[00000196827FFFA0] block_cache mark-for-deletion piece: 11181
[00000196827FFFA0] block_cache mark-for-deletion piece: 10215
[00000196827FFFA0] block_cache mark-for-deletion piece: 11853

Approx 5 lines per second appear in the libtorrent cache log. It seems to have some inefficiency in cache flushing on Windows. Will try to dig deeper.

Edit 2: The disk cache is allociated via a lots of _aligned_malloc buffers. It is the freeing of these bazillion tiny pieces that is being slow on Windows.

Edit 3: use_disk_cache_pool=true fixes it.

@sandersaares commented on GitHub (Nov 18, 2018): During the "hang", libtorrent is doing this: ``` [00000196827FFFA0] block_cache mark-for-deletion piece: 2025 [00000196827FFFA0] block_cache mark-for-deletion piece: 13084 [00000196827FFFA0] block_cache mark-for-deletion piece: 5529 [00000196827FFFA0] block_cache mark-for-deletion piece: 1624 [00000196827FFFA0] block_cache mark-for-deletion piece: 12604 [00000196827FFFA0] block_cache mark-for-deletion piece: 13225 [00000196827FFFA0] block_cache mark-for-deletion piece: 5404 [00000196827FFFA0] block_cache mark-for-deletion piece: 15711 [00000196827FFFA0] block_cache mark-for-deletion piece: 12521 [00000196827FFFA0] block_cache mark-for-deletion piece: 4710 [00000196827FFFA0] block_cache mark-for-deletion piece: 111 [00000196827FFFA0] block_cache mark-for-deletion piece: 9382 [00000196827FFFA0] block_cache mark-for-deletion piece: 5358 [00000196827FFFA0] block_cache mark-for-deletion piece: 8263 [00000196827FFFA0] block_cache mark-for-deletion piece: 2728 [00000196827FFFA0] block_cache mark-for-deletion piece: 7009 [00000196827FFFA0] block_cache mark-for-deletion piece: 1266 [00000196827FFFA0] block_cache mark-for-deletion piece: 4868 [00000196827FFFA0] block_cache mark-for-deletion piece: 6882 [00000196827FFFA0] block_cache mark-for-deletion piece: 4835 [00000196827FFFA0] block_cache mark-for-deletion piece: 5599 [00000196827FFFA0] block_cache mark-for-deletion piece: 10084 [00000196827FFFA0] block_cache mark-for-deletion piece: 1119 [00000196827FFFA0] block_cache mark-for-deletion piece: 12300 [00000196827FFFA0] block_cache mark-for-deletion piece: 11181 [00000196827FFFA0] block_cache mark-for-deletion piece: 10215 [00000196827FFFA0] block_cache mark-for-deletion piece: 11853 ``` Approx 5 lines per second appear in the libtorrent cache log. It seems to have some inefficiency in cache flushing on Windows. Will try to dig deeper. Edit 2: The disk cache is allociated via a lots of `_aligned_malloc` buffers. It is the freeing of these bazillion tiny pieces that is being slow on Windows. Edit 3: `use_disk_cache_pool=true` fixes it.

deekerman commented

2026-02-21 19:02:10 -05:00

Author

Owner

@sandersaares commented on GitHub (Nov 23, 2018):

Fixed in libtorrent: https://github.com/arvidn/libtorrent/pull/3488

I request this fix be included in qBittorrent.

@sandersaares commented on GitHub (Nov 23, 2018): Fixed in libtorrent: https://github.com/arvidn/libtorrent/pull/3488 I request this fix be included in qBittorrent.

deekerman commented

2026-02-21 19:02:10 -05:00

Author

Owner

@thalieht commented on GitHub (Nov 23, 2018):

Should be in qBt when it uses a libtorrent version with that fix.

@thalieht commented on GitHub (Nov 23, 2018): Should be in qBt when it uses a libtorrent version with that fix.

deekerman commented

2026-02-21 19:02:11 -05:00

Author

Owner

@xavier2k6 commented on GitHub (Sep 30, 2019):

@sandersaares Try 4.1.8 & report back.

@xavier2k6 commented on GitHub (Sep 30, 2019): @sandersaares Try 4.1.8 & report back.

deekerman commented

2026-02-21 19:02:11 -05:00

Author

Owner

@sandersaares commented on GitHub (Oct 20, 2019):

4.1.8 no longer reproduces the issue. In fact, I saw it go away around 4.1.5 or so already (not sure when exactly, was using custom build with the fix for some time span). Just forgot to close this earlier!

@sandersaares commented on GitHub (Oct 20, 2019): 4.1.8 no longer reproduces the issue. In fact, I saw it go away around 4.1.5 or so already (not sure when exactly, was using custom build with the fix for some time span). Just forgot to close this earlier!