JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #1  
Old 03.03.2020, 11:02
loiSTank loiSTank is offline
I will play nice!
 
Join Date: Feb 2020
Posts: 7
Default 100% CPU while downloading

I'm seeing 100% CPU usage while downloading, but normal CPU usage when "Stop Downloads, but finish running ones" is engaged. Strongly suspect this is an issue with JDownloader cycling constantly through the download list without limiting itself, possibly tied to the real-debrid plugin.

Bandwidth and download speed don't seem to be relevant factors. 100% CPU usage happens whether there's one download at 30kB/s or 10 totaling 20MB/s. Turning on "Stop Downloads, but finish running ones" immediately drops CPU usage to much lower levels, even with several downloads running.

Hosts on my download list include uploaded, mega, 1fichier, fileboom, keep2share, filejoker, but I can't tell if this behavior is tied to any of them. It's not related to actual transfers from any particular hoster. Also using real-debrid, and the real-debrid plugin may be involved somehow. Tried deactivating it and CPU usage dropped, but so did transfers, so it's not clear if that's where the problem is.

On windows, 16GB ram, JDownloader set to use 1GB, actual usage is around 300MB. System resources aren't an issue.
Reply With Quote
  #2  
Old 03.03.2020, 16:33
pspzockerscene's Avatar
pspzockerscene pspzockerscene is offline
Community Manager
 
Join Date: Mar 2009
Location: Deutschland
Posts: 72,961
Default

Hi,

this possibly is a known issue which only happens for https downloads.
Please search the forum for "cpu ssl".
Also, please post your hardware setup here and a log:

Please post your log-ID here | bitte poste deine Log-ID hier.

-psp-
__________________
JD Supporter, Plugin Dev. & Community Manager

Erste Schritte & Tutorials || JDownloader 2 Setup Download
Spoiler:

A users' JD crashes and the first thing to ask is:
Quote:
Originally Posted by Jiaz View Post
Do you have Nero installed?
Reply With Quote
  #3  
Old 05.03.2020, 15:11
loiSTank loiSTank is offline
I will play nice!
 
Join Date: Feb 2020
Posts: 7
Default

I don't think SSL is likely to be the issue here. SSL is turned off in the real-debrid plugin. It's not turned off in individual hoster plugins (like uploaded.to) so I don't know if that affects things, but I've noticed that DNS requests are taking up significant CPU resources (20%+) when this is happening. As soon as "Stop Downloads, but finish running ones" is turned on, that behavior stops and CPU usage drops to normal levels, even if transfer speeds are high. If SSL were causing issues, I'd expect CPU usage to scale with transfer speeds, but that's doesn't seem to matter much.

Hardware is an i5-7700HQ, 16GB ram. Windows 10 is fully updated.

Tried to get logs, but I just got tons of error messages. Tried restarted jDownloader a bunch of times, but the errors were consistent:

Last edited by Jiaz; 17.04.2020 at 19:12.
Reply With Quote
  #4  
Old 16.04.2020, 06:56
loiSTank loiSTank is offline
I will play nice!
 
Join Date: Feb 2020
Posts: 7
Default

Is this being looked at? I never got a response and it's still tagged as user feedback required. I still have the problem inconsistently, and it still seems tied to runaway DNS requests when it does happen.
Reply With Quote
  #5  
Old 17.04.2020, 19:12
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 81,021
Default

Quote:
If SSL were causing issues, I'd expect CPU usage to scale with transfer speeds
unfortunately not the case. GCM cipher require much more CPU power than other ciphers, and there are known performance bugs/regressions in older Java versions that can easily cause full load on cpu. that means 20 mbyte/s can easily max out 8 cores on the system due to this issues. the more connection(eg downloads, chunks) the worse the problem.

You logs are too large for upload
Quote:
413 Request Entity Too Large
Please do the following. Close JDownloader and delete the logs folder. Start JDownloader again and enable Debug logs, see Settings->Advanced Settings->Log.debugmodeenabled and restart JDownloader.
Now wait for high cpu usage, stop downloads, create log and post shown logID here
__________________
JD-Dev & Server-Admin
Reply With Quote
  #6  
Old 18.04.2020, 00:11
loiSTank loiSTank is offline
I will play nice!
 
Join Date: Feb 2020
Posts: 7
Default

Quote:
Originally Posted by Jiaz View Post
unfortunately not the case. GCM cipher require much more CPU power than other ciphers, and there are known performance bugs/regressions in older Java versions that can easily cause full load on cpu. that means 20 mbyte/s can easily max out 8 cores on the system due to this issues. the more connection(eg downloads, chunks) the worse the problem.
I still don't think that's likely to be the problem. I was able to reproduce 100% cpu usage with 0kb/s transfer speeds, and I've consistently seen it with transfer speeds below 100kb/s. "Stop Downloads, but finish running ones" will drop cpu usage to normal levels no matters the transfer speed, whether that's 100kb/s or 20mb/s. This seems tied to heavy dns request activity.

Here's the log I just was able to make:

17.04.20 17.58.41 <--> 17.04.20 18.00.25 jdlog://7587815302851/
Reply With Quote
  #7  
Old 21.04.2020, 16:58
pspzockerscene's Avatar
pspzockerscene pspzockerscene is offline
Community Manager
 
Join Date: Mar 2009
Location: Deutschland
Posts: 72,961
Default

Jiaz is working on that issue.
Seems like a lot of real-debrid URLs + retries + a lot of URLs in linklist is like frying your CPU ...

-psp-
__________________
JD Supporter, Plugin Dev. & Community Manager

Erste Schritte & Tutorials || JDownloader 2 Setup Download
Spoiler:

A users' JD crashes and the first thing to ask is:
Quote:
Originally Posted by Jiaz View Post
Do you have Nero installed?
Reply With Quote
  #8  
Old 21.04.2020, 18:01
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 81,021
Default

Please try again with next core update. Real-Debrid plugin (and others) could lead to many necessary *is connection working/offline* checks which have encountered and were part of the log. That lead to tight loop of: JD try next link -> link currently temp. unavailable -> check online status -> next link and so on and on...when you have MANY links in list, and max downloads higher number than current running, then JDownloader will *burn* through the list causing logs of unnecessary checks
__________________
JD-Dev & Server-Admin
Reply With Quote
  #9  
Old 20.01.2023, 21:26
choin choin is offline
Super Loader
 
Join Date: Oct 2017
Posts: 27
Default

Encountered this and am surprised this is still a thing. Shouldn't it be possible to add some timers to not cause infinite loops?

Had to lower max concurrent downloads to current amount of transfers to cut the CPU usage.
Reply With Quote
  #10  
Old 23.01.2023, 14:40
pspzockerscene's Avatar
pspzockerscene pspzockerscene is offline
Community Manager
 
Join Date: Mar 2009
Location: Deutschland
Posts: 72,961
Default

Hi choin,
this is most likely not an "infinite loop" issue.
Please read this:
https://support.jdownloader.org/Know...ng-downloading

If you still think you found a bug, please let us know how to reproduce that one and provide a log.

Please post your log-ID here | bitte poste deine Log-ID hier.

-psp-
__________________
JD Supporter, Plugin Dev. & Community Manager

Erste Schritte & Tutorials || JDownloader 2 Setup Download
Spoiler:

A users' JD crashes and the first thing to ask is:
Quote:
Originally Posted by Jiaz View Post
Do you have Nero installed?
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 05:32.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.10 Beta 1
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.