SABnzbd with a long queue causes "Bad Gateway" error

Morning,

I have over 100 items in my download queue (Cutoff found better qualities of a lot of episodes :slight_smile: ), and since the items have been in the queue I have been getting an error pop up every couple of minutes that say “[GET] Bad Gateway: /nzbdrone/api/queue”

NZBDrone and SABnzbd are both running on the same server (Debian Jessie). This also seems to cause the load on the server to skyrocket.

Is there a way to limit the SABnzbd calls, EG. get first 20 items, once done get next “page” of items. Or even increase the timeout for the call.

Thank you,
Clifford.

Load in which app? SAB or drone? For 100 items paging really isn’t required.

Thats a UI error, there should be a corresponding error in the logs of drone, we’ll need that to determine where it is failing and what we need to do to fix it.

Load on my Linux server, both NZBDrone and SABnzbd are running on the same machine.

I’m also running via an Nginx reverse proxy, I have just increased the timeout of the proxy server, and not I’m not getting the errors, but “/nzbdrone/api/queue” is taking around 1.2min (longest was 2.5min so far)

Everything looks like it’s working fine, just very slow (I know it’s an Ajax call and relient on internet, but this is also on my home network, even using the IP and port)

Network load? Process? which process?

If you load up the UI of drone in your browser and use the dev tools (F12 in Chrome/Firefox and it will also tell you how long it was waiting for versus time to receieve) you can tell how much data was grabbed, but 1.2 for 100 items its super slow, I’ll double check that we’re not doing anything wrong on our side.

You’re seeing the same slowness on your LAN as well, connect via the local IP? What if you bypass the proxy?

I can confirm it’s not a network issue, network is running at 1Gbps and if I copy files it goes at full speed.

I was checking chrome dev tools, thats how I found it takes 1.2min to complete the request

Just checked on one request now (/nzbdrone/api/queue)
Blocking: 2.176ms
Sending: 0.154ms
Waiting: 1.8min
Receiving: 21.059ms

The rest of the application is flying it’s just that request, I don’t remember this being an issue when I had a small queue (1 or 2 items) the queue is only so long now because NZBDrone found a whole bunch of backlog items (which I’m gratefull for)

And yes this is the same if I load via the IP address vs Nginx proxy.

Thanks for the info. I’ll do some testing with a large queue and see what I can find.

I have 137 items in my queue using the latest master release (2.0.0.1533) and the latest develop (2.0.0.1557), both result in getting the queue within a few seconds. What version are you running?

I tested on Windows, but it shouldn’t make much of a difference.

I’m running on Debian (Jessie):
NzbDrone Ver. 2.0.0.1533
Mono JIT compiler version 3.0.6 (Debian 3.0.6+dfsg2-12)

I’ve tried checking through the logs and nothing stands out, also the logs tend to fly by when it starts the RSS lookup.
Will try and install the latest version of mono and see if that helps, might be a while as I have to compile from source :confused:

Might be able to use the Ubuntu package, this is how we recommend updating on Ubuntu: http://stackoverflow.com/a/13384233/882971

I installed from Debian Repos, but this had Mono 3.0.2 and I though that might be part of the issue.

I think I have found the issue, the “/nzbdrone/api/queue” seems to download information from the internet, and if SABNzb is using all the bandwidth then it’s a slow request. Today the requests are taking 30-40s, and the only change I have made was for SAB to download at half the bandwith.

My queue is now 14 items and “/nzbdrone/api/queue” now take 10s

Queue down to two items and it’s running at about 1.5s

I don’t believe /nzbdrone/api/queue downloads anything from the internet, even still that is outrageously slow.

Is there mono 3.2 or 3.4 available as a package? If not you may need to compile it because they have many fixes.

There isn’t a package available yet, had issues compiling Mono, but have found a solution to that and will try again later.