Lower BiglyBT Memory consumption

[marc0nline]

I like the robust nature of BiglyBT as I did with Vuze, my only issue with running my server is memory consumption. I tried BiglyBt to see if they were going to tackle that issue, but its as great a memory hog as was Vuze. It takes more memory then any other program on my server. In comparison I also run qBitorrent it consistently is running half the memory no matter what I am using it for.

I hope the BiglyBT team will take the memory consumption issue soon. Thanks

[parg]

How much memory do you consider too much? I'm not being facetious, its just that given that machines these days often come with 8GB of memory or more, 256MB (for example) isn't very significant.

[marc0nline]

BiglyTy runs 760mb consistently on my server.

Marc

---

From: parg notifications@github.com Sent: Sunday, October 15, 2017 10:30:44 AM To: BiglySoftware/BiglyBT Cc: marc0nline; Author Subject: Re: [BiglySoftware/BiglyBT] Lower BiglyBT Memory consumption (#92)

How much memory do you consider too much? I'm not being facetious, its just that given that machines these days often come with 8GB of memory or more, 256MB (for example) isn't very significant.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/BiglySoftware/BiglyBT/issues/92#issuecomment-336715344, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AbRnBFTw3P7-KbHsq_uqgbzoVGhfWFXEks5sshcUgaJpZM4P5ul7.

[parg]

How many torrents do you have running (actively downloading/seeding)?

[marc0nline]

Right now 3. All seeding stops after 2.0 ratio. All the rest have stopped. I use to archive after 2.0 ratio on Vuze.

Marc

---

From: parg notifications@github.com Sent: Sunday, October 15, 2017 10:37:13 AM To: BiglySoftware/BiglyBT Cc: marc0nline; Author Subject: Re: [BiglySoftware/BiglyBT] Lower BiglyBT Memory consumption (#92)

How many torrents do you have running (actively downloading/seeding)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/BiglySoftware/BiglyBT/issues/92#issuecomment-336715799, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AbRnBCVT5hdL22VdWjajvu8NqN0B3j2qks5sshiZgaJpZM4P5ul7.

[parg]

OK, that is ridiculous :) What OS are you running on? Could be that the Java runtime is being given too much memory in the virtual machine and it just uses it

[legacychimera247]

i second this...the more biglybt is open the more it consumes memory, i've arrived at almost 550 mb for 4 torrents opened while transmission is less than 100 mb with more torrents opened...ok is like comparing david to goliath but you get the idea...even vuze always was a memory hog and that was one of the reasons i switched from that to transmission on my linux machine (since on linux biglybt and vuze seems to be more resources hog than on windows)

[parg]

The reason is probably that the JVM size is high - what tends to happen is that garbage is allowed to hang around as the JVM has, say, 500MB to spare and it doesn't bother much until that limit is reached. Look at the settings under Tools->Options->Startp & Shutdown - what does it say the maximum JVM heap is?

[legacychimera247]

says that 254 mb is the maximum heap... btw just made a quick comparison : transmission after 1 hour of usage is 50 mb with 20 torrent of which 6 where active deluge after 15 minutes of usage is about 60 mb with 4 torrents active biglybt after 5/6 minutes from having opened it is about 348 mb with 2 torrents only (and after some hours of usage it can reach even 400/500 mb of ram even if java heap is set at 200)

i know modern computers have tons of ram but it would be nice to have some sort of optimizazion...i just have 3 gb of ram and i can clearly see the difference with deluge (not citing transmission because it's clearly designed to be light) and/or when biglybt is opened...

[parg]

If all you ever run is a few downloads then try setting the max heap to 128M and see how that works out

[legacychimera247]

tried, and with just 2 download...after about 20 minutes biglybt was using about 300 mb ram...

[parg]

Do you have any anti-virus/firewall software that might be scanning the BiglyBT process and leaking memory? If you have a heap limited to 128M and the process has grown to 300 then the memory must be being allocate outside of the JVM heap - BiglyBT operates almost entirely on the heap, the only 'direct' memory is used for file system cache and I assume you haven't configured anything significant under Tools->Options->Files->Performance Options

[legacychimera247]

i'm on linux, so no anti-virus to me, and no i haven't touched anything in "performance options"

by the way i have opened biglybt with no torrent at all, and after a few minutes (with no torrents at all) is already 275 mb and it's growing...and the heap is set at 128 mb...vuze had the same exact problem...

[parg]

I've got BiglyBT running on Kubuntu 16.04 with a max heap set to 64MB - when I check the JVM usage stats logged to the thread_1.log/thread_2.log files in the 'logs' directory under the config dir (.biglybt) I see lines like the following (after running for 20 minutes)

[03:17:56] Thread state: elapsed=10000,cpu=1135,max=DH Precalc(255/2%),mem:max=61952,tot=61952,free=22240

This shows the total heap the JVM can grow to, the current max it has taken and the free memory - 22MB free out of 64MB (ish) - This is with the I2P Helper plugin running as well which can use a bit of memory.

Now linux's view of memory usage is obviously different as it accounts for the Java infrastructure, memory required to hold the BiglyBT code, network buffers etc.

Perhaps take a look at https://stackoverflow.com/questions/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used

Bottom line, the Java virtual machine has a fairly large footprint.

[nkedel]

Old issue, but might be worth trying -Xss256k -- I believe on 64-bit Linux the default thread stack size is 1M, which adds up /really/ quickly.

[ferdnyc]

As @nkedel said, old thread, but I wanted to throw another data point out there:

It turns out, the-client-that-shall-not-be-named version 5.7.6.0, the version released after the BiglyBT fork, has a MASSIVE memory leak in it. It will grow to fill the entire 6GB of RAM in the machine I have it running on in the space of just a few days, necessitating a restart of the client to get it back down to sane levels.

(Honestly, that was one of the major factors that spurred me into pulling the trigger on a cutover to using BiglyBT full-time. Despite feet-dragging from one private tracker that operates with a strict client whitelist, which has necessitated setting the client-id plugin to identify as the old client. I'm still working on getting BiglyBT officially supported there.)

BiglyBT 1.5.0.0 thankfully does not exhibit the same ravenous memory consumption, but I can't say for certain there are no leaks in the code. Just now, I restarted a BiglyBT instance that had been running for around 2.5 days, and after it finished starting up the total RAM usage on the machine had dropped from 30% to 21%, with the java process's memory consumption reduced from 15% to 6.2%. That seems roughly typical of BiglyBT's much-more-reasonable memory consumption patterns. It does grow, but pretty gently.

For comparison, though I'm not sure how much use this information really is, some lines logged in thread_2.log before the restart:

[05:33:45] Thread state: elapsed=10001,cpu=410,max=SWT Thread(196/1%),mem:max=233472,tot=132096,free=62063 [05:44:45] Thread state: elapsed=10000,cpu=1439,max=SWT Thread(1171/11%),mem:max=233472,tot=134144,free=61365

and after restarting and running for ~ 30 minutes:

[06:02:34] Thread state: elapsed=10000,cpu=323,max=SWT Thread(67/0%),mem:max=233472,tot=166400,free=51920

vs. the lines logged by the last two longest-running instances of the-other-client before I shut it down:

[11:42:28] Thread state: elapsed=10000,cpu=3563,max=AsyncDispatcher: BackupManagerImpl.java:90(1411/14%),mem:max=466432,tot=293888,free=214074

[11:26:02] Thread state: elapsed=10000,cpu=1012,max=SWT Thread(420/4%),mem:max=466432,tot=293376,free=135442

(Those are from different runs on different days, they just coincidentally happen to have been logged around the same time of day.)

There hasn't been any torrent activity in BiglyBT since I restarted it (beyond the usual announcing of seeded torrents to their trackers). I have a few queued up that I'll go start now, and I'll see what the memory consumption looks like afterwards. I suspect that, to the extent that BiglyBT does grow, it primarily occurs when it's actively processing torrents, not just sitting there relatively-idle. (Which would make sense, of course.)

[Makere]

My BiglyBT runs into over 10Gigs of RAM usage after running for a week.

[ferdnyc]

My BiglyBT runs into over 10Gigs of RAM usage after running for a week.

Man, that's crazy. Mine definitely doesn't grow nearly that fast, though it does seem a bit leaky.

My current 1.5.0.1_B14 session has been running for 8d 11h, according to Statistics > Transfers.

It's downloaded 10.33 GB and uploaded 38.68 GB. Statistics > Cache shows 15 MB of cache used out of 33.5 MB total.

Memory usage of the java process is 43%, making up the majority of the system's total 59% RAM usage. (This is on the same scale that I reported a just-restarted BiglyBT java process consuming 15% of RAM during startup, and 6.2% after it finished starting.)

The most recent line in thread_1.log is

[17:26:45] Thread state: elapsed=10000,cpu=466,max=SWT Thread(212/2%),mem:max=233472,tot=185856,free=60598

...Hey, @parg , the numbers in those log lines, what do they represent? Specifically, what are the units of the cpu= figure, and what do the two numbers after the name of the max consumer represent? Like, I see that SWT Thread(212/2%) there, but 212 what? 2% of what?

I ask mosty because, despite having rougly the same memory stats, that only-running-for-30-minutes process I mentioned in my previous comment had logged SWT Thread(67/0%) — that first number (67) is a lot lower than what my current instance logged (212), despite the fact that it's just sitting idle, same as the other one. (But it's been up and running for a week, not 30 minutes.) I'm wondering if perhaps it's leaking... unterminated SWT threads? Is that what there are 212 of?

The other thing, in comparing to @Makere 's usage: I have a bunch of potentially memory-hogging plugins disabled in Options > Plugins. I've switched off all of the following so they're never loaded, since I don't use the features they provide:

• Distributed DB
• Distributed Tracker
• Swarm Discoveries
• Share Hoster
• I2P Helper
• Tor Helper
• LAN Peer Finder
• UPnP Media Server
• Friends

I wonder if a memory-hogging plugin could explain some of the vast difference in memory usage we're seeing?

I do have a couple of other potentially heavy/leaky plugins installed, most notably BiglyBT Web Remote, Magnet URI Handler, and RSSFeed Scanner. I wouldn't be surprised if RSSFeed accounts for a good portion of my memory usage, but I use its functionality heavily so disabling it isn't on the table.

[Makere]

My BiglyBT runs into over 10Gigs of RAM usage after running for a week.

After posting this, I decided to do some more tweaking in my settings;

• Found out that I had a random folder inside the "active" folder in the settings directory, proceeded to delete it
• Dropped Max Heap from 384 to 192 and Min to 16 MB
• Dropped "peers to save per torrent" from 500 to 50 (I'm feeling this might've caused issues)
• Enabled sleep mode in Distributed DB (what does this mean in practice?)
• Turned off the "Update anonymously" (idk what this does in reality either)

Some other things that I think that might cause my issue but I don't want to disable yet:

• Mainline DHT
• IP Filters (I have a huge list)

I'll drop by in around a week to update (with more details) if my memory usage has improved in any way. I think the high memory usage might cause the #481 that I reported before.

[ferdnyc]

• IP Filters (I have a huge list)

Oh crap, right! It totally slipped my mind to include that: I use an external IPFilter list, updated online, with 475,850 IPs currently blocked. So, apparently that bit of the code's actually very efficient. :grin:

[ferdnyc]

Dropped "peers to save per torrent" from 500 to 50 (I'm feeling this might've caused issues)

TBH I wouldn't expect that to affect memory consumption; it only controls how many peers are written out to disk in the state files used for crash-recovery, but no matter what number you set that to, the same number of peers are still in memory regardless. High values would have more of a performance impact, potentially.

In terms of memory consumption, AIUI the most critical settings that relate directly to torrent handling are all in Options > Transfer — things like "Max connections globally", "Max connections per torrent default", "Max upload slots per torrent default". After that, there's Options > Files > Performance Options which controls memory usage related to file caching, via things like "Maximum {read,write} requests queued (in MB)", the overall "Size of cache in MB", etc.

Dropped Max Heap from 384 to 192 and Min to 16 MB

Depends how many torrents you typically have (a) active, and (b) loaded, of course, but I've had troubles with heap exhaustion when I've set the max heap down that low. YMMV.

BiglyBT shows my current max heap as 265.28 MB (set via the default -Xmx256m on the command line), and I'd be reluctant to reduce it very much because ~/.biglybt/logs/thread_[12].log typically shows a free= value (which I believe corresponds to free heap space?) between 40000 and 100000. Assuming that's in KB, it means there are times when BiglyBT consumes over 200 MB of my heap space while it's active.

[Makere]

I'll drop by in around a week to update (with more details) if my memory usage has improved in any way.

I was at 8GB of usage today with 21 torrents open and 8 active torrents, seems that the memory usage goes up by 2GB daily approx, I had to restart for other reasons.

Depends how many torrents you typically have (a) active, and (b) loaded, of course, but I've had troubles with heap exhaustion when I've set the max heap down that low. YMMV.

Yeah was running into exhaustion pretty quick, so fixed it up to 256 which seems to work fine.

AIUI the most critical settings that relate directly to torrent handling are all in Options > Transfer

I had these as "Auto", I changed it to

• Max upload slots: 15
• Max conns per torrent: 100
• Max conns globally: 500
• Max seeds per torrent: 500

After that, there's Options > Files > Performance Options

I've changed these settings before, I have:

• cache in MB: 4
• Max write requests queued: 1MB
• Max read requests queued: 1MB

I use the following plugins: Auto Pilot, Web Remote, mlHDT, ScaneRSS. I uninstalled the uTP plugin and UPnP server plugin now to see if they affect memory usage at all.

Not sure what to do next to improve the ram usage.

[ldgbc]

Not sure if it high CPU or RAM usage that causing my client to freeze frequently (aside from a slow PC).

I recently discover this thing call Excelsior Jet (https://www.excelsiorjet.com/internals). I wonder if BiglyBT will be able to benefit from it and solve this issue?

But it is a paid software and closed source (?) so it can only be use as an experience or reference learning. Alternatively, if you paid for it, I suppose you could use the Open Source code of BiglyBT and build it using the Excelsior Jet.

Edit: I found this. https://www.excelsiorjet.com/buy " Standard Edition Set Free "

[parg]

Do you have a lot of torrents actively running? If so you will either need to increase the memory available to BiglyBT (sounds like you don't want to) or decrease the number of active torrents.

Pre-compilation with tools like excelsiorjet has been tried before and wasn't workable. Feel free to experiment with it yourself though! All BiglyBT source is available from https://github.com/BiglySoftware/BiglyBT

[ferdnyc]

If you notice from the Excelsior chart, they're claiming that performance under the standard JVM increases over time — that is, it starts out slow but gradually improves as the runtime code is optimized. Which isn't a situation BiglyBT is encountering, or worried about. (It isn't likely to be a situation most Java applications run into, really. That sort of thing would be far more of a worry for relatively short-lived servlets, for which immediate performance is more critical than long-term.)

[Achaean]

Since this issue is still open, I wanted to add my own experience too. I'm not sure if this is the case, but it seems strange to me, that running 1-5 torrents while starting with a memory usage of ~350MB, after 5-6h Bigly uses >1.5GB of memory and keeps occupying.more and more. Of course. restarting Bigly solves the problem temporarily, but I never had such a problem, with Vuze.

Java 1.8.0_181 (64 bit) Oracle Corporation /usr/lib/jvm/java-8-openjdk-amd64/jre

SWT v4922, gtk/3.22.11, zoom=100, dpi=96 Linux v4.9.0-8-amd64, amd64 (64 bit) B1.8.0.0/4 az3 On Devuan ASCII x64 KDE.

[parg]

What does it say under Tools->Options->Startup & Shutdown - current heap maximum (under Java Options)

If it large then set it to something like 256m and restart

Check after restart that it has taken effect.

Also look in the 'logs' folder in the BiglyBT config dir - check thread_1.log and thread_2.log. They details the current java memory usage.

[Achaean]

THANKS parg! :-)

It was saying 240. Setting it specifically -> 256, didn't help.

No thread_2 log! Only thread_1 here. Not surprisingly, I can't interpret it! :-) I'm attaching it here. A.

thread_1.log.zip

[parg]

OK, so it had a reasonable limit. The memory usage you are seing isn't coming from the Java runtime as it is limited to 256MB. The thread log shows that it is actually using a relatively small amount of that:

mem:max=233472,tot=188928,free=131483

means that the max is 233MB (240MB minus some overhead), it has currently grown the heap to 189MB but at that point in time 131MB is actually free (due to garbage collections).

So the memory usage you are seeing is outside of the control of BiglyBT. I know linux memory stats can be rather confusing. e.g.

https://serverfault.com/questions/341579/what-consumes-memory-in-java-process

[parg]

and https://serverfault.com/questions/138427/what-does-virtual-memory-size-in-top-mean

[Achaean]

Strange!!! Linux Java port, seems to be a not so reliable solution, as it's Windows counterpart indeed. Keeping this is mind, this bug seems to be ~6yo, but I was using Vuze all these years (at Debian) without this leak problem (with even older kernels than my current one). It really, confuses me! :-) Oh well...lets hope it'll be eventually fixed! :-)

[parg]

confuses me too :)

[DumbJoe]

If so you will either need to increase the memory available to BiglyBT (sounds like you don't want to) or decrease the number of active torrents.

How exactly do you increase heap memory on a nix system such as Debian? According to this page: https://wiki.vuze.com/w/Java_VM_memory_usage it says I can do that by looking at JAVA_ARGS=" line in the shell script but no such line exists. I looked up -Xmx to see if that's anywhere and it is, on the line ${JAVA_PROGRAM_DIR}java -Xmx8192m \ and changed it like so as I was getting out of memory error on the log files. It was at 4096m before which fixed it the last time. Now I can't even get into the webpage...

Anyways, on that; where do I put -XX:MaxDirectMemorySize=32m so I can set it to 32MB as apparently it's not suppose to be greater than that or your ram amount since that amount defaults to the heap max which in this case is 8GB....

But yeah, I also would need to increase file handles or decrease timeout (or do both!) as per this thread: https://stackoverflow.com/questions/5656458/java-net-socketexception-too-many-open-files as I also got the same error in the log files as well.

[parg]

Generally you shouldn't need to set the "max DIRECT memory size" unless you are getting explicit errors about running out of direct memory space.

How many active torrents (i.e. downloading or seeding) do you have? 8GB of heap is quite a lot...

[DumbJoe]

Generally you shouldn't need to set the "max DIRECT memory size" unless you are getting explicit errors about running out of direct memory space.

I was going to paste in the error but apparently my logging file didn't log down that error and I've already restarted BiglyBT so all errors are gone now and I don't think I can scroll back up to old errors anyways.... oh well, the max direct memory size is set to the same as the heap memory anyways since I don't know how to cap that.

How many active torrents (i.e. downloading or seeding) do you have? 8GB of heap is quite a lot...

Last I checked was about 40 to 50, the rest are stuck in queuing mode.

[parg]

40 to 50 active torrents shouldn't require more than 400MB heap, nowhere near 8GB...

Go to Options->Startup & Shutdown

At the bottom there's a 'JVM memory usage history' item with a 'View' button - press that.

There's some information on it in https://github.com/BiglySoftware/BiglyBT/wiki/Performance-Tweaks

[DumbJoe]

40 to 50 active torrents shouldn't require more than 400MB heap, nowhere near 8GB...

Well apparently it does or else why would it complain?

Go to Options->Startup & Shutdown

At the bottom there's a 'JVM memory usage history' item with a 'View' button - press that.

What is the equivalent of that on the non-GUI version?

[parg]

Look in the thread_1.log and thread_2.log files in the logs directory

[DumbJoe]

Found the latest ones in the save folder of the logs folder:

1621423009925_thread_1 1621423009925_thread_2

Would throw them in here but apparently there's a 65k character limit...

[parg]

You seem to be running with a maximum heap size of around 360MB (from the max= values)

[DumbJoe]

You seem to be running with a maximum heap size of around 360MB (from the max= values)

Wait only 350MB? So what did changing the heap memory size do? Nothing? Was it only a placebo effect when I restarted that it conveniently worked with a high heap memory rating?

[parg]

no idea...

[DumbJoe]

Perhaps the command was only applicable on Vuze but on BiglyBT it's different.....