CPU Usage

High CPU Usage

High CPU usage withing the BiglyBT process can have many causes:

Normal Situations

• Hash Checking

When pieces of a file are downloaded they are checked for correctness by calculating their unique hash. This takes a small amount of CPU per piece and if you are downloading quickly this can add up. This process also occurs when you manually recheck a file via the 'force recheck' menu option

• Transcoding

Converting video file formats is CPU intensive, so when you are doing this you will see high CPU usage. Note that in this case the CPU usage is registered against the converter application rather than the BiglyBT process.

• Cryptography

In general cryptography (encryption, decryption) is resource intensive. If you install the I2P Helper Plugin then you will see elevated CPU usage as a result of its continual cryptographic operations.

Abnormal BiglyBT Causes

• Memory Exhaustion BiglyBT runs within a Java virtual machine (JVM) - this uses a garbage collected 'heap' to store data. The size of the heap is constrained. If you have a lot of active torrents the heap can become full. As this happens the JVM spends more and more effort trying to make space in the heap and this in turn causes increased CPU usage.
• Bug Occasionally a bug within BiglyBT might cause a thread to loop (incorrect locking of access to a HashSet would be a good example of a rarely triggered situation)

Abnormal External Causes

Third party applications such as virus scanners often inject their components into the BiglyBT process in order to monitor network traffic. If there is a bug in these components, or they have performance issues, this will appear to be an issue with the BiglyBT process itself. For example, ESET Smart Security version 8

Diagnosis

BiglyBT monitors the various threads within the process and logs details of the most active thread to rotating log files named thread_1.log and thread_2.log in the 'logs' folder of the configuration folder. An example line from these files is

[21:36:13] Thread state: elapsed=10001,cpu=2790,max=PRUDPPacketHandler:sender(1404/14%),mem:max=253440,tot=66640,free=36124

The first 'max=' entry shows the thread name most active in the last 10 seconds (in this case 'PRUDPPacketHandler:sender') followed by the amount of CPU used (14%). Following this is the current JVM memory situation. The 'max' value here (253440) gives the maximum size the heap can grow to in KB. The 'tot' value gives the current total size of the heap (66640) in KB, so in this case around 250MB is available but only 66MB is in use. The 'free' value indicates how much of the 'tot' allocated value is actually free for use.

If you have a 'tot' value that has grown to around 'max', and a small 'free' value then you are running low on heap memory.

The above example was from a user with the ESET induced CPU usage issue.

If you are running I2P then you will see threads with names like 'YK Precalc' and 'Job Queue n/m' as active, this is normal.

If a thread is using a very large amount of CPU (in the case of a bug perhaps) then the log file will also contain a stack trace of the offending thread. This can be very useful to the developers so please report this.

Reducing CPU Usage

A few tips on how to reduce BiglyBT CPU usage

• Upgrade to the latest Java version, uninstall any old Java before doing so.
• Read about Good Settings and follow the advice. For example:

1. Stay with downloading 1 or 2 torrents at the same time. Downloading tons of torrents at the same time is normally just a waste of cpu as BiglyBT in most cases can max out your download speed with just a few active torrents downloading. Setup config to queue max downloads to 1 or 2 and BiglyBT will start queued downloads automatically when you have finished one torrent.
2. Under Tools->Options->Transfer: change the value in the field "Maximum number of connections per torrent" from 0 (unlimited) to the result of 300 divided by the number of active downloads you have. For example: If you have 3 downloads running at the same time (300/3=100) change the value to 100. The value of 300 in this formula can vary from 100 to 1000, depending on the Windows version and the kind of connection (dsl&router/ISDN/cable/...). Start with 300/numberofdownloads and reduce the value (300) in 10th steps until you have a stable internet connection. At the end, BiglyBT will run smoother and you won't get disconnected by too many socket connections.

• Decrease update frequency of the user interface. Under Tools->Options->Interface->Display: change "Update GUI every" from 250ms to a higher value (for example 2sec). This can make a big difference under Mac OS X. Also adjust the other updating frequency options there e.g. (table sorting, graphical bars).
• Select a low-activity window... Torrent 'General' window makes the cpu load medium/low. Torrent 'Details' window makes cpu load high/medium. 'Library' / 'My torrents' window makes cpu load low. This is just cpu load from GUI. Mac OS X is most affected by this GUI loads. On Mac OS X, minimise to dock or * Hide BiglyBT will ease cpu load caused by the GUI.
• Close the console window.
• Turn off logging.
• Turn off IP Filters. If this solves the problem, try reducing the number of IP's you're blocking.
• Uninstall Safepeer, as it is incompatible.
• Try removing all your plugins by moving them out of the plugins directory, both under Program Files/BiglyBT/plugins and Documents and Settings/~username/Application Data/BiglyBT/plugins. If it makes a difference, move each plugin back one by one, restarting BiglyBT each time to see which gives you the problem.
• Try disabling any program that is limiting the upload speed of jawaw.exe (e.g. NetLimiter)