SABnzbd Forums

Version: 0.7.20
OS: QNAP os 4.1.3 build 20150217
Hardware: TVS-863, 16gb RAM, currently 3x6TB RAID 5
Install-type: NAS package, then I believe I installed a wrapped that looks for updates each time sab is restarted
Skin: Plush
Firewall Software: router
Are you using IPV6? no
Is the issue reproducible? intermittent

Recently loaded the queue up to around 2.5 - 3 TB worth of data. Problem started where sab will become unresponsive and eventually crash and burn. grepping through logs for "signal" I found some Signal 15's being caught. Not sure where else to turn in regards to narrowing down where the problem is.

Any guidance or assistance pointing me in the right direction would be greatly appreciated.

Just happened again... I noticed the web interface was not responding any more, tail log and this is the last line in sabnzbd.log:

2015-03-12 15:11:58,162::DEBUG::[interface:421] API-call from 127.0.0.1 [Sonarr/2.0.0.2850 (RestSharp/105.0.1.0; Linux/3.12)] {'start': '0', 'apikey': 'XXX', 'limit': '0', 'mode': 'queue', 'output': 'json'}

2-3T is a very big queue.
SABnzbd has never been tested with such a queue size.
It's very likely that some design choices have been made that are less than optimal for such a queue.

Your log line suggests that Sonarr is trying to retrieve the full queue in one gulp.
That is not a good idea, since it causes SABnzbd to allocate large amounts of RAM.

It's a new NAS, so that explains the large queue... I think It's ~8TB in 2 months. (-8

I'll look to limit the size Sonarr is attempting to fetch. Thanks for the reply.