qBittorrent official forums

I have no idea if that is even possible in Windows.

It isn't, there has been untold third party "Memory Managers" for every Windows release since Windows 3.1 and none have really worked.

Based on what I have learned (thanks all!), I vote for a configurable setting within qBittorrent to choose between OS and application caching schemes (at least for Windows).

Yeah, I can confirm the problem as qBt was using over 4 GB of RAM that was immediately freed when I closed it. I remember the same problem happening in the builds following 2.7.3 which was then fixed and is now apparently back. Just when I thought I had finally moved over to qBt for good, I'm now back on uTorrent.

I've had qBT opened and seeding for 42 days now. Around ~28 torrents and with maximum cache of 2 GB with an expiry time of 240 seconds. Not one time has qBT gone above ~600 MB though it is theoretically allowed to use much more. I have mixed torrents, both private and public and with varying upload speeds.

So I'm pretty sure qBT is not at fault here. With windows you can never be sure..

BTW, this is on win7 x64 (soon make the switch, though).

qBT 32bit will crash trying to use  a 2GiB cache.

You do NOT need a large cache, doing so WILL trigger Windows to 'run away' with memory and trying to use a large cache is wasteful of OTHER resources.

soon make the switch

To what?

GNU/Linux of course : ) Debian and some nice DE that doesn't suck (looking at you gnome 3.X).

You could try using Dayman's 64bit build. It should work with over 2GB cache without crashing.

Oh yes Gnome still appears to have been designed on  a Commodore 64 using 'Teletext' style graphics.

My last remaining M$ Windows machine was swapped out last week, so every bit of hardware is on Linux in one disguise or another, definitely a case of "M$ Windows has now left the building."

[quote="pcguy"]
Based on what I have learned (thanks all!), I vote for a configurable setting within qBittorrent to choose between OS and application caching schemes (at least for Windows).
[/quote]

This still looks like a huge memory leak, not a cache behaviour.
(sorry, I know it's an old thread.)

Well, I welcome your remark.

I have not been using qBittorrent for quite some time, because of this behaviour.
I am running my bittorrent on a Windows 2008 R2 server and clearly see the memory leak in the Taskmanager.
In the last versions of qBittorrent it was getting so bad, that qBt would crash with in 3-4 days of running.

I am currently using Deluge 1.3.6. It is behaving better (that qBt) but also showing signs of memory leak.
Based on my observations the memory leak evolves much more quickly if you are downloading or uploading at high bandwidth (>2 MB/sec.).
It may be related to disk cache or it may me related to connection management.

I hope that someone some where will look in to this.
I would love to start using qBt again.

I am currently using Deluge 1.3.6. It is behaving better (that qBt) but also showing signs of memory leak.

Because it is a Windows problem not a client problem.

Why do you keep on saying this.

If you took the time to read what I wrote, you will see that it is the qBittorrent process that reports the memory use.
So how can that be a Windows problem?

This is a Windows client, and if it is not able to run in a Windows environment, then the program is faulty and not Windows.
At least, that is my sincere belief.

You have not proved conclusively that qBT is using all the memory, you have however shown that Windows is reserving memory when TWO different BitTorrent clients are running, which is not the same thing as the client actually using the memory directly. The BitTorrent  process is the catalyst for the problem, not the actual problem

So no matter how many times you complain about "qBT using memory", it cannot and will not be 'fixed' by changes to the client. UNLESS you consider making the client limit the number of "file handles" it opens to a small number which will severely limit the number of active tasks that can be running.

If I remember correctly the topic you are talking about:

In very simple terms: qbt opens a file handle for read/write, the OS is responsible for the caching of the writes/reads. I don't know what algorithm Windows' uses for this but it seems that this algorithm goes out of control if you have many reads/writes. Moreover that memory is associated with qbt even though qbt cannot directly free that memory even if it closes the file handles.

When I say qbt I really mean libtorrent. There may be a Windows API that controls the OS' cache behavior but I dunno. You'll have to pester the libtorrent dev at his bug tracker. This is something that qbt cannot control, unless we switch from OS' caching to manual caching.
I am positive on making an option for this in the GUI for the next major version. If someone could open an issue and inform I'll tag it. (otherwise I'll surely forget about this).

[quote="ciaobaby"]
You have not proved conclusively that qBT is using all the memory, you have however shown that Windows is reserving memory when TWO different BitTorrent clients are running, which is not the same thing as the client actually using the memory directly. The BitTorrent  process is the catalyst for the problem, not the actual problem

So no matter how many times you complain about "qBT using memory", it cannot and will not be 'fixed' by changes to the client. UNLESS you consider making the client limit the number of "file handles" it opens to a small number which will severely limit the number of active tasks that can be running.
[/quote]

I haven't shown anything, and I really think you have me confused with someone else in this thread.
And I haven't really complained at all, I have reported an issue that apparently a lot of users are experiencing.

It is qBittorrent (libtorrent) responsibility to work within the Windows framework.
Not the other way around.