-
Notifications
You must be signed in to change notification settings - Fork 154
Performance Tweaks
BiglyBT runs within the Java garbage collected virtual machine (JVM). The JVM is configured with a maximum amount of memory that it is allowed to use when allocating objects, the 'heap'. Periodically the JVM runs 'garbage collection' cycles of varying degrees of aggressiveness, searching for and freeing objects that are no longer needed. Garbage collection takes time and effort so if the JVM has plenty of free heap memory it is somewhat lazy and allows the garbage to build up.
BiglyBT sets the JVM memory limit to around 250MB to cater for a wide range of usage scenarios. This means that often the JVM will use a significant amount of this due to lax garbage collection. If you want to understand what memory is actually required then join the beta program (see the Help menu) and then observe the contents of the two log files 'thread_1.log' and 'thread_2.log' (usage is rotated) in the "logs" folder in the BiglyBT configuration folder. A line is written to the current file every 10 seconds detailing the most active thread along with the current memory usage.
Since version 2303 there has been a simpler way to view recent memory usage, go to Tools->Options->Startup & Shutdown and hit the button labeled 'JVM memory usage history'
Here is an example:
[00:50:32] Thread state: elapsed=10000,cpu=3260,max=GMReceiver(2044/20%),mem:max=7431168,tot=346112,free=115296
The memory figures are given in KB, so this line roughly says that the maximum configured JVM heap is around 7.4GB, the total currently allocated from within that maximum is 346MB and there is 115MB (of the 346MB allocated) that is free (in other words 231MB is in use)
If you look at subsequent lines you will probably see that the amount free drops until a garbage collection cycle occurs at which time it'll jump back up again. If the free memory gets too low then the allocated memory will be increased.
As mentioned earlier, the garbage collector has various levels of aggression. A 'full GC' can be triggered by going to the Debug menu in BiglyBT and selecting 'Run GC'. This is will cause the garbage collector to stop everything and free as much memory as possible. You can see the result in the next line logged to the current file.
[00:52:12] Thread state: elapsed=10000,cpu=2947,max=GMReceiver(1825/18%),mem:max=7431168,tot=326112,free=254955
After this major memory clean up the total (326MB) has been reduced (memory handed back to the OS) and the free has significantly increased (255MB) meaning that actually only 71MB is in use. If the current number of torrents running within BiglyBT is similar to your normal usage, and you want to save some memory, you can probably change the JVM heap limit from the default 250MB to something lower, perhaps 120MB (giving the JVM some room for garbage). If you make the heap too small then the JVM will spend a lot of time garbage collecting to make space.
To change the JVM heap memory make sure that your 'mode' is set to advanced (Options->Mode) and then go to Options->Startup & Closedown and set the 'Max heap memory' to (say) 120MB and restart.
The I2P helper plugin supports various BiglyBT features around anonymity. It also supports the overall I2P network by contributing to the routing of anonymous connections between other peers. The cryptographic aspects of the network can be quite CPU intensive, so if you have a CPU limited computer and are not actively using the BiglyBT features that require the I2P plugin it is worth considering disabling/uninstalling it.
Generally the fewer active (downloading/seeding) torrents you have running at a given time within BiglyBT, the less the CPU usage. The 'Queue' rules (Options->Queue) have settings to control how many overall active torrents you can have along with various scheduling options.
Changing the garbage collector used by the Java virtual machine may improve things, take a look at
https://www.reddit.com/r/BiglyBT/comments/198n6yt/fyi_generational_zgc_is_awesome_for_my_bigly/
bigly help