Need advice on tuning

[jhmiller]

Hi,

I don't mean to hijack this topic but as my question is similar to the OP's i thought i would post here.

system:
Intel E6850 @3GHz
4BG ram
Debian squeeze (headless)
Indexing 12 groups on both newznab and nzebd (not simultaneously)
 
I did try to set this up a few weeks ago but could not convert the database so gave up.
Last night i decided to try again but without converting the database. I did a git pull and applied the database patches. I watched the threaded screen scripts for about an hour and was getting loads of around 0.25. Checking the site showed the new items starting to appear.
Woke up this morning to check how it was going and found that loads have shot up to 20+ and cpu was 100%
On Newznab my load tops at around 1.2 (ish) so when i seen nzebd running happily at 0.25 i thought thats it im definitely swapping over but i dare not to now unless i can (with your help) figure out what is going wrong

I am unsure where to begin tracking down what could be causing this to happen so any thing you guys can suggest would be greatly appreciated.

Miller

[jonnyboy]

Take a minute or two and look at htop to see what process is using all of the resources. The screen scripts can't produce that amount of load unless you have a hung process or two.

[jhmiller]

I just tried running the simple.sh file instead of the screen threaded start.sh and it started off ok but then looks to get stuck while doing stage 6.
I left it like this for 10 minutes and killed it when the load started reaching 10.
update_releases.php 1 true was just fluxuating its cpu usage from 0 to 9% and its memory usage was 88.8 - 90.1%

Code: [Select]

Stage 6 -> Categorize and post process releases.

passwordstatus = -1
available to process = 0

passwordstatus = -2
available to process = 0

passwordstatus = -3
available to process = 0

passwordstatus = -4
available to process = 0

passwordstatus = -5
available to process = 0

passwordstatus = -6
available to process = 0
Processing 100 NFO(s), starting at 0 * = hidden NFO, + = NFO, - = no NFO, f = download failed.
++++++++++++-+++++-++++++++++++++++
It then carried on with the rest of the script and ran again after 60 seconds, again it look to have froze on stage 6 but with only 5 +'s i then killed that and waited for it to re-run stage 6, this time no +'s so i killed the whole script (ctrl-c)

I can't see any other process that looks to be hanging (mediainfo, unrar etc)

[jonnyboy]

It's not getting stuck, it is searching for hidden nfo's. That, unfortunately takes time.

[jhmiller]

It's not getting stuck, it is searching for hidden nfo's. That, unfortunately takes time.

I thought that each + was 1 processed release, so your saying its normal for 1 release to take longer than 10 minutes to find information for the release?

Newznab can get the latest headers and post process them all in under 10 minutes, this includes checking for passwords, getting screen shots and nzb contents.

Thanks for your help but i will still with Newznab for now.

[jonnyboy]

It's not getting stuck, it is searching for hidden nfo's. That, unfortunately takes time.

I thought that each + was 1 processed release, so your saying its normal for 1 release to take longer than 10 minutes to find information for the release?

Newznab can get the latest headers and post process them all in under 10 minutes, this includes checking for passwords, getting screen shots and nzb contents.

Thanks for your help but i will still with Newznab for now.

The plus means that it found an nfo and it downloaded it. It is not waiting on that one, it is the next one that it is searching for. And yes, I have seen it take 5 minutes to find an nfo.

Maybe you should stay with nn+. But, nn+ isn't better or faster at anything.

[xeddog]

I just thought I'd add my experience here.  After re-installing my OS all nZEDb associated software, I initially did not think my problem was solved.  When running the tmux scripts, it appeared that  post processing  was still hanging.  I let it run for as long as probably 2 hours and it still seemed to be hung saying pocessing 25 releases and then where the releases were supposed to be counting down I saw 23 left . . .  for a loooooong time.  It never changed and system responsiveness was pretty bad taking 4-5 seconds just to move the cursor a few inches.

So just to see if I could play with it some, I went and changed the nZEDb tmux  post processing to false and restarted the tmux scripts.  No problems for hours and hours which pretty much convinced me that post processing was the problem.  So I started running "postprocess.php all true" manually in a separate terminal session and went to go get something to eat and take a break.  When I came back about an hour later it was hung saying 23 left again.  But just as I was about to terminate it I saw it suddenly go to 22 left.  So it wasn't hung, just taking forever.  Over the next couple of hours it finally finished so I started it again.  This time it still looked like it might be hung, but eventually kept on going and it didn't take as long this time.  At this point I changed the command to "postprocessing.php allinf true" so it would keep recycling itself.   I let it run this way for a while and before long things seemed like they started moving in what I would call normal fashion.  I closed the window, changed the nZEDb tmux setting to turn post processing back on, restarted tmux, and it has been working like a champ for at least a full day now.  I have even added a few more groups (a couple at a time, but two or three of them were pretty big groups) and no more issues.  (knock on wood)

I don't know why a few of the nfo's took so long, but things have become quite smooth for me now.  I have three downloaders running on three different machines now, all three of which are running SABnzbd+, SickBeard, and Couch Potato.  The differences are:  One machine has a newer I7processor with 6GB ram and is using nn+ for it's indexer, another one also has an older I7 with 4GB ram and is using an online indexer, and the third one has an even older Core2 processor with 4GB ram and is using nZEDb.  I gotta say that I'm really becoming impressed with nZEDb now.  Yesterday it downloaded a show HOURS earlier than nn+, and the system using the online indexer still hasn't found it.  The people developing this system are doing a fantastic job as far as I'm concerned, so if you are having problems don't give up.  I'm sure they'll fix it.

X

   

[jonnyboy]

As was just pointed out in irc, some nzbs are quite huge. One was found to be 400MB for a 1.8TB release.

If you do not want the huge releases, then set the max size to create a release and those nzbs will be discarded.

Also, the default time to kill postprocessing of 300 seconds probably caused you infinite loop trying to process that release.

[jhmiller]

I just thought I'd add my experience here.  After re-installing my OS all nZEDb associated software, I initially did not think my problem was solved.  When running the tmux scripts, it appeared that  post processing  was still hanging.  I let it run for as long as probably 2 hours and it still seemed to be hung saying pocessing 25 releases and then where the releases were supposed to be counting down I saw 23 left . . .  for a loooooong time.  It never changed and system responsiveness was pretty bad taking 4-5 seconds just to move the cursor a few inches.

So just to see if I could play with it some, I went and changed the nZEDb tmux  post processing to false and restarted the tmux scripts.  No problems for hours and hours which pretty much convinced me that post processing was the problem.  So I started running "postprocess.php all true" manually in a separate terminal session and went to go get something to eat and take a break.  When I came back about an hour later it was hung saying 23 left again.  But just as I was about to terminate it I saw it suddenly go to 22 left.  So it wasn't hung, just taking forever.  Over the next couple of hours it finally finished so I started it again.  This time it still looked like it might be hung, but eventually kept on going and it didn't take as long this time.  At this point I changed the command to "postprocessing.php allinf true" so it would keep recycling itself.   I let it run this way for a while and before long things seemed like they started moving in what I would call normal fashion.  I closed the window, changed the nZEDb tmux setting to turn post processing back on, restarted tmux, and it has been working like a champ for at least a full day now.  I have even added a few more groups (a couple at a time, but two or three of them were pretty big groups) and no more issues.  (knock on wood)

I don't know why a few of the nfo's took so long, but things have become quite smooth for me now.  I have three downloaders running on three different machines now, all three of which are running SABnzbd+, SickBeard, and Couch Potato.  The differences are:  One machine has a newer I7processor with 6GB ram and is using nn+ for it's indexer, another one also has an older I7 with 4GB ram and is using an online indexer, and the third one has an even older Core2 processor with 4GB ram and is using nZEDb.  I gotta say that I'm really becoming impressed with nZEDb now.  Yesterday it downloaded a show HOURS earlier than nn+, and the system using the online indexer still hasn't found it.  The people developing this system are doing a fantastic job as far as I'm concerned, so if you are having problems don't give up.  I'm sure they'll fix it.

X

   

Thanks xeddog, i will give your method a try.

I did not mean to sound like i was having a go at the devs, just trying to point out that something was not quite right with the nfo finding stage. I still believe that it was the cause of my system load hitting 20+ but if i can bypass whatever release is causing issues i can then get a true idea of performance. Like i said, the first time i ran it i was getting loads of around 0.45

[jonnyboy]

There is an option in webui admin to limit the max size for releases. There is no need to index releases that are excessive in size.

[slypknot]

My advice, if you're going to opt to use a seriously under-powered system, you need to learn ALL of the ins and outs of the code along with seriously construct your my.cnf and memory allocation.

IMHO, it is not worth it.  Machines are cheap these days and you'd be better off using this box as a samba server.  If usenet is as important to you as me, you'll invest in it as I have.

[Killerc]

My advice, if you're going to opt to use a seriously under-powered system, you need to learn ALL of the ins and outs of the code along with seriously construct your my.cnf and memory allocation.

IMHO, it is not worth it.  Machines are cheap these days and you'd be better off using this box as a samba server.  If usenet is as important to you as me, you'll invest in it as I have.

In all fairness i agree with this, you very much need to understand the system, what you're doing and why and also the bits you are running blindly. Doing the absolute least groups possible, at which point it gets to the question, why are you indexing on a box that blatantly can't handle it? The cost of running it for a yr is more than most decent sites charge for VIP and it's always going to be behind because you simple cannot keep up on PP due to the lack of resources it has. If its just for fun fair enough, but its something to take into account.

Edit: Small sidenote, jonnyboy, any chance those options in the site options for min and max filesize for making a release can jump into a form thats NOT bits, skim reading it took me a bit to realise i was using kB by default as nothing uses bits anymore lol (30720 is much easier as a concept than 31457280... )

[jonnyboy]

Edit: Small sidenote, jonnyboy, any chance those options in the site options for min and max filesize for making a release can jump into a form thats NOT bits, skim reading it took me a bit to realise i was using kB by default as nothing uses bits anymore lol (30720 is much easier as a concept than 31457280... )

Yes. But I have to find all of the references first.