Networker

Re: [Networker] Slow index browsing - additional

2003-07-28 15:27:05
Subject: Re: [Networker] Slow index browsing - additional
From: "Paige, Steve" <Steve.Paige AT CHEP DOT COM>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Mon, 28 Jul 2003 15:26:51 -0400
Thanks Ted, we didn't have a choice at this DR we were stuck with the slower 
processors - 250 Mhz.  We have 2 unboxed v880's with (4) 1.2 Sparc III cpus 
sitting here I have been drooling on, but not sure if management is going to 
let me swap our e6500 for it!  Are you saying entire NetWorker product is 
single threaded?  That does stink.  Any suggestions for getting more speed out 
of this thing, other than getting me hands on that 880? If it is single 
threaded, I'd say it was not a scalable product.

You run on a Solaris system?  What else is in your setup?  jukeboxes? using a 
SAN? backing up to disk? Yea, Solaris has much better memory management than 
2.6.  We run Solaris 8 on our e6500 for the Legato server.

*       Backup server: Sun Enterprise 6500 - (10) 400 Mhz cpus and (10) gigs of 
memory running Solaris 8
*       (4) storage nodes including backup server - (2) SunFire 6800's and (1) 
v880 in Tape SAN config
*       over 100 UNIX clients & over 100 NT/Netware server
*       L11000 with (16) DLT7000 drives and L700 with (12) 9840 drives
*       over 10 TBs a night gets backed up, OS and databases (UNIX, NT, 
Netware, M$ Exchange, Oracle, SAP, SQL, etc)


Your thoughts about version 7.  I heard 7.1 was due out in Oct. and Legato 
support told us to hold off for 7.1

Thanks for your 2 cents man

Steve

*******************************************
Steve Paige
UNIX System Administrator
407-355-6819 Desk
407-929-6483 Mobile
steve.paige AT chep DOT com




-----Original Message-----
From: Reed, Ted G II [ITS] [mailto:ted.reed AT MAIL.SPRINT DOT COM]
Sent: Monday, July 28, 2003 12:53 PM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] Slow index browsing - additional


$.02
----
The truth is, any single process used by legato is a single threaded process.  
Therefore, both nsrd and nsrmmdbd jobs use a single processor for their work 
(and hopefully not the same one).  Most of the time, this means that you will 
see the nsrd as the hottest process on the server.....but only on the single 
CPU it is utilizing.  I have noticed that on 7.0 however, the nsrmmdbd is the 
hot job, but only during the nsrim process.  We have noted dramatic changes in 
overall CPU usage by the nsrd process in the 7.0 upgrade.  It seems to be 
primarily the result of divvying up the DB into smaller, more manageable 
chunks.  Our 4x400Mhz e450 is now viable as a master again, instead of being 
continually pegged on a single cpu!!

In a nutshell, your DR box should consolidate more of that power into a smaller 
number of CPUs.  While you do need some processor cycles to run the nsrmmd jobs 
to interact with the tapes, your primary user and abuser of cpu cycles will be 
nsrd on any pre-7.0 implementation.  In fact, our system (pre-7.0) was so 
single-cpu loaded prior to 7.0 that we were investigating a 2x1.2GHz v280 as a 
new master.  Now that is not so much an issue.

If you are leasing the DR space, ask for more per-cpu horsepower.  As long as 
your cap is 250MHz/cpu, it will be painful to do much simultaneous legato 
work.....even 7.0 might not help as much as you'd like.  One last thought:  
Legato IS scalable, what it ISN'T is truly multi-threaded, so a single CPU can 
STILL be a bottleneck.  But the faster that cpu is, the more scalable legato as 
an ENVIRONMENT is.

Other thoughts on 7.0:
nsrim runs much longer and with nsrmmdbd as the 'hot' process
GUI remains responsive during nsrim and/or worst of backup cycle!!
During any but worst client backup load, nsrd < 1 cpu resources!
nsrmmdbd:  the "new" legato bottleneck?

--Ted


PS.  Another user of this list told me about Solaris 2.6 binaries of Solaris 
being the primary build available.  If you are running Solaris 8, you might 
query Legato about a Sol8 built binary of the networker application.  
Apparently this user has seen a marked difference due to Solaris 8 build 
optimizations (memory, libraries, etc) that are NOT there in the 2.6 build 
binaries.  YMMV.



-----Original Message-----
From: Paige, Steve [mailto:Steve.Paige AT CHEP DOT COM]
Sent: Monday, July 28, 2003 7:14 AM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] Slow index browsing - additional


At DR we had (10) 250Mhz in a e6000.  We have similar problems in Orlando with 
a e6500 with (10) 400Mhz cpus and 12 gigs of memory.  I figured the nsrd ps was 
single-threaded, how about nsrmmdbd?  The sad thing, NetWorker is the only 
non-system resource running on this system!  This is the first diaster reovery 
test where I have been in charge of the acutal restores and not just the 
rebuilding of systems and I was very disappointed with how NetWorker ran.  If 
we can not restore all our data at the same time (with in reason) in the event 
of a actual Disaster, this product worthless.  It seems NetWorker is not 
scalable and we have gone as far as we can with this product.  

More thoughts please.

Steve 

*******************************************
Steve Paige
UNIX System Administrator
407-355-6819 Desk
407-929-6483 Mobile
steve.paige AT chep DOT com




-----Original Message-----
From: Davina Treiber [mailto:treiber AT HOTPOP DOT COM]
Sent: Monday, July 28, 2003 6:03 AM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] Slow index browsing - additional


On Mon, 28 Jul 2003 09:16:35 +0200, Riaan Louwrens
<riaanl AT SOURCECONSULTING.CO DOT ZA> wrote:

>I would like to jump onto the back of this question and ask whether there
>are any "utilities" for Unix / Solaris etc. We as well have a 480R box that
>seems to only use 1 of the 2 processors. Is there a way to "force"
Networker
>to use a second (i.e. 3rd / 4th - 10th) processor ?
>
>I know from all the guides and diswcussions that Legato is NOT single
>threaded (allegedly), the performance tuning guide does not really say
>anything helpfull at all (disk and tape write speeds tests are 100%). I
>guess performance tuning / debugging on the various OS's are only gained
>through experience ...

This has been discussed fairly recently on the list.

NetWorker as a whole product is not single-threaded, however the nsrd
process is. nsrd can often be the bottleneck, and can be seen to take up
100% of one CPU while others are idle. Over the years, Legato have improved
the efficiency of nsrd, the latest improvement being the splitting of the
res files in 6.2 and 7.0. There is still more to do IMHO.

Because of nsrd being the bottleneck, you will usually find that for a
NetWorker server, faster CPUs is much preferable to more CPUs. A large NW
server will be struggling with 250MHz CPUs on a Sun box, however many of
them you have.

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

<Prev in Thread] Current Thread [Next in Thread>