Very long shutdown times using SQLite resume data storage

[JodanJodan]

qBittorrent & operating system versions

qBittorrent: 4.6.3 x64 Operating system: Windows 11 Pro 22H2/2023 x64 Qt: 6.4.3 libtorrent-rasterbar: 1.2.19.0

What is the problem?

With ~56000 torrents and while using the SQLite backend for resume data storage, qBittorrent takes 5 minutes to shutdown every time, whether or not I've added new torrents. Startup takes 9 seconds.

Resource usage is consistent at around 0.2-0.4% CPU, 1250MiB memory and ~0MiB/s disk.

I've noticed that a torrents.db-wal (157MiB) nearly equal in size to torrents.db (176MiB) is created, so my naïve guess is that there's either 1) an error in the WAL checkpoint logic, or 2) the synchronous PRAGMA is set to full instead of normal, causing qBit to wait on disk flush for every page.

Steps to reproduce

1. Enable SQLite resume data storage.
2. Load a few tens of thousands of torrents.
3. Shut down qBittorrent.

Additional context

[BitTorrent]
Session\ResumeDataStorageType=SQLite

Log(s) & preferences file(s)

No response

[glassez]

With ~56000 torrents and while using the SQLite backend for resume data storage

Have you no such problem with "Legacy" (.fastresume files based) backend?

[glassez]

the synchronous PRAGMA is set to full instead of normal,

We don't use such a PRAGMA.

[glassez]

causing qBit to wait on disk flush for every page.

I still can't believe that it would take 5 minutes for a file about 150 MB in size (unless of course you are using some kind of faulty disk or some kind of "perversion" such as an external or network drive).

[JodanJodan]

Have you no such problem with "Legacy" (.fastresume files based) backend?

Legacy takes >10min for both start and shutdown for me, which is why I switched. SQLite is still a performance improvement in this scenario, it's just that the shutdown times are orders of magnitude above what they should be for a database this small.

We don't use such a PRAGMA.

Does that mean it's using the default full? normal is safe for the WAL mode currently used by qBit.

unless of course you are using some kind of faulty disk or some kind of "perversion" such as an external or network drive

I'm running qBit non-containerized using an M.2 NVMe. CrystalDiskInfo reports no health issues.

[glassez]

Issue title and description give the false impression that the problem is precisely because of SQLite storage. But this is clearly not the case:

With ~56000 torrents and while using the SQLite backend for resume data storage, qBittorrent takes 5 minutes to shutdown

Legacy takes >10min

[glassez]

We don't use such a PRAGMA.

Does that mean it's using the default full?

Are you competent to modify qBittorrent to use another value and test it? Otherwise I could create PR that uses normal if you don't mind to test binaries built on GitHub.

[glassez]

Note, that often the "long shutdown" problem is related to sending stop event to all announced trackers.

[sledgehammer999]

Are you competent to modify qBittorrent to use another value and test it?

Or you can use a program like DB Browser for SQLite to edit the DB and change the PRAGMA. Or at least inspect it's current value.

[glassez]

Are you competent to modify qBittorrent to use another value and test it?

Or you can use a program like DB Browser for SQLite to edit the DB and change the PRAGMA. Or at least inspect it's current value.

IIRC, this PRAGMA is connection related so it doesn't change mode permanently.