qBittorrent official forums

I constantly am going back and fourth between qbittorrent and deluge, but am pretty sure i'll end up with qbittorrent in the end. Anyway, for purely curious reasons, I wanted to ask if you know why qbittorrent uses about double the memory roughly, than deluge, when using same latest libtorrent version as backend.

In all RAM numbers I mention, I get them from the python script psmem.py, which is very good at reporting precise private and shared memory usage of processes, and I quote the full private+shared value, but the shared value is always very small and e.g. only about 5mb more than the private.

When downloading a single torrent in default config, deluge uses 80mb and qbittorrent uses 311mb. That is of course because deluge has defined by default the disk-cache to 8mb(512*16kb blocks), whereas qbittorrent defines to use libtorrents own disk-cache management which is total RAM / 8.

However, when changing qbittorrent to use 8mb as diskcache then qbittorrent uses 170mb, which is still over double of deluge's 80mb. The only time I can get comparabel memory usage from the two clients, is when setting qbittorrents disk-cache to 1mb, which then uses about 80mb like deluge, but then download speed is greatly reduced to 4 times lower download speed than deluge. Enable/disable OS-cache doesn't have any influence.

However, qbittorrent uses less RAM than deluge when started fresh and no torrent started yet, where deluge uses about 65mb and qbittorrent 55mb. Qbittorrent also uses slightly less cpu than deluge on my system.

I'm not complaining here, and i'm greatly appreciative against the devs for making such a nice app and giving it away for free to us - thank you so much, but i'm just curious about this. I know unused RAM is wasted RAM, but I prefer keeping RAM usage as low as possible, like with CPU, to let other stuff on the system have the most resources available as possible - I have 4gb, well 3.3gb only listed when checked from terminal.

Thank you so much in advance for any insight or thoughts on this please.

are you using a blocklist?  when using an ipfilter it loads into memory using more RAM.

i haven't bothered to set disk write cache until i read your thread so now i have 8MB/60s expiry/enable OS cache and with 9 torrents in client / 4 active /ipfilter loaded after 5 minutes i have 126MB and slowly rising every few minutes/v 3.3.6

i am noticing qbittorrent getting heavier and also not terminating when i close

Nope, no blocklist, although I use a socks5 proxy, but have it disabled for testing/comparissons. Yes, the memory starts low and then slowly increases, showing that the cache is working I guess, and yes 8mb setting halfs the memory, but still puzzling that deluge is lighter with same setting. Well, of course it's only the cache and the app also takes memory and the two apps are totally different, but my point is that without torrents added, then qbittorrent is actually lighter in memory than deluge and it's only when downloading(haven't checked seeding yet), that it uses "much" more than deluge. Also, I agree with that qbittorrent sometimes doesn't close correctly and then you can't start it again afterwards, but it's not that often and I fix it by running 'pkill -9 qbittorrent' and sometimes the python search plugin is the culprit, so 'pkill -9 python3'.

I don't mind qbittorrent is using more memory if it is somehow a more effecient way of doing things, but just wanted an explanation from someone in the know if possible.

I'm greatly impressed with qbittorrent btw, it's every bit as good as utorrent and then some + without the annoyances(before deluge and qbittorrent I used utorrent-server, and years ago utorrent on win32). Again thank you so much to the devs, you rock. I have decided to stay on qbittorrent btw, and uninstalled deluge for good. The only thing I miss from deluge is a CLI UI(deluge-console), as I prefer terminal apps for everything except browsers(though with pentadactyl), but the deluge-console where too simplistic with almost no options to show/handle torrents(but socks5 proxy support and a plugin to enable libtorrent options like force_proxy and anonymous_mode - though qbittorrent have them built-in without 3rd-party plugin-use). Honestly, if I didn't needed socks5 proxy support, then I would hapilly use rtorrent in a tmux session(socks5 tunneling can be setup I believe, with additional tools, as a workaround, but then no UDP support like uTP and DHT).

My earlier thread on qBT's memory use:
index.php/topic,2042.0.html
and especially this:
index.php/topic,2042.msg11037.html#msg11037

Note: All my tests were done on the windows version of qBitTorrent!

Thanks alot switeck for the link, interesting read

Strangely, then now after running it again for some times, then I cannot reproduce the higher memory of about 170mb when setting the disk-cache to 8mb like deluge, and it now uses the same roughly as deluge of 71 - 80mb at the end of a single download. Also, leaving disc-cache default as 0 with libtorrent 1.1 vs 1.0.9, uses 300 vs 120mb accordingly(the qB 3.3.6 package on arch-linux installs as dependency latest libtorrent 1.1, and to test the "recommended" 1.0.9 version I had to build qB myself against libtorrent 1.0.9 as else it wouldn't run and complained about missing correct libtorrent version).

When starting qB without any downloads, then it can also differ by about 12mb from time to time.

Again psmem.py values reported here throughout.

@mhertz: It seems like your IGPU eats up 768mb of ram anyhow.
If you really run Linux, you should be fine with 128mb or 256mb of ram dedicated to your integrated gpu.
You can set this value in the BIOS.

Other than that, are you sure you checked the right value at "free -m"?
Even with 4gb only, you should have plenty of ram left with any decent DE. (XFCE, Cinnamon, MATE.)

Thanks Peter for your reply!

First, i'm an idiot, of course it's the GPU taking up the memory(not talking about qBt here, btw)! I don't know how I could forget that, but thanks for reminding me(I spent alot of time 6 years ago finding out first why the 64bit linux used 4 times more memory than the 32bit and second the issue you brought up of the reserved GPU memory chunk, so thanks for reminding me of that so I can lower it some).

EDIT: Hmm, it's only listing 256MB, strangely through 'lspci -v -s 00:02.0': EDIT2: Sorry 'free -m' reports 3630MB, so I remembered wrong stating 3.3GB only before...

Second, I report values from the ps_mem.py script, which is highly regarded as one of the most accurate memory reporters around. It's reporting private bytes by each process + shared bytes divided by processes using that shared chunk(the private bytes where the ones to compare of course). I highly recommend googling it Or just get it here simply: https://github.com/pixelb/ps_mem/raw/master/ps_mem.py - right-click and download, make it executable(chmod +x ps_mem.py) and add it to PATH somewhere, or run it from it's folder directly with 'python ./ps_mem.py'.

I also should have mentioned that I used the deluge daemon without UI when comparing to qBt, which isn't fair I know, sorry. I now use qBt-nox, which uses less RAM(when setting disk-cache the same) and CPU than deluge and I can fire up the webUI when wanting to track progress(I setup qBt-nox as handler for torrents/magnets in firefox through an automated script I made, just like when I used the deluge daemon). The only thing I "miss" from qBt-nox, is a CLI frontend and ditching QT for a non GUI version(60MB dep for only qBt-nox of 4.77MB on my system and luckilly my distro; arch, has a light QT5-base package with the extras splitted off in seperate packages), but dreaming I know and again please don't take this as me being ungrateful as i'm truly not!(I need SOCKS5 support and so cant use rtorrent, though i'm playing with it now through a VPN instead, but is pretty taxing on CPU with the openvpn encryption, negating the lightness of rtorrent, though still about on par with qBt-nox, but i'm testing how often the VPN drops, if at all), but i'm very grateful for qBt(-nox) nonetheless of course.

When choosing an app, then I go by which I like the best, and when I can't decide, then I go by which is lightest, that's just what i've always done. Yeah, I know 4GB is alot and especially for me running without DE and using a standalone tiling-WM and run CLI-apps only except browsing, but I still want as much resources available as possible(for VMs etc during testing various things) and for everything running as fast as possible in general(without risking paging to disk), but I do see your point of course I'm also sometimes switching between firefox/pentadactyl and chromium/cvim, and chromium can take up 2GB easilly, though generally max 1.2GB. as I rarely exceed 10 tabs at a time. Of course it can possibly also be tweaked and haven't really dwelled into that yet, but also thought it's probably because of the "one-process-per-tab" sandboxing functionality.

Thanks again and sorry for blabbing on so much

- Martin.