Networker

Re: [Networker] Too many tape mounts

2003-07-31 20:19:57
Subject: Re: [Networker] Too many tape mounts
From: Stan Horwitz <stan AT TEMPLE DOT EDU>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Thu, 31 Jul 2003 20:19:44 -0400
Thanks Ted. This is very helpful information. Yes, you're right, nsrd is
usually at the top or high up on the process list. We are going to get
three additional CPUs on order for our Enterprise 450 and more RAM. The
CPUS are rated at 450Mhtz. The machine we migrated from is 500Mhtz, if I
remember correctly.

On Thu, 31 Jul 2003, Reed, Ted G II [ITS] wrote:

>7.0 also does a much better job of handling tape mount requests than 6.x.  The 
>reason your tape mounts and your interactive sessions with networker are 
>unresponsive is most likely due to the "nsrd" process running at maximum 
>available CPU cycles.    nsrd is your probable bottleneck for all these 
>problems and I'm guessing at the times of these slowdowns you will find "nsrd" 
>at the top of the list of cpu intensive processes.....probably eating all 
>available CPU cycles.
>
>We had the same basic problem while on 6.x and made the following changes:
>        10 drives @ 10 target sessions per ( 100 target sessions )
>        Set primary group (150+ clients) to 68 savegroup parallelism (<7 
> drives)
>        set secondary groups to approximate same value as number of clients 
> (ie 20 client group @ 4 sessions per client = 80 potential target sessions, 
> savegroup parallelism set to 20 or 2 drives)
>        We tried to make it so the total number of open target sessions at any 
> one time were less than/equal to the 100 total sessions available.
>
>You say you recently migrated....what per cpu speed did you use to run at
>and what per cpu speed do you have now?  And if you are using one single
>cpu server for both master AND data mover, then you are definitely
>beating up that cpu and it's no wonder you bog down.  And yes, I can
>confirm, you can hit a point of no return when it can take 30 minutes to
>get a gui back for a tape mount ..... and where things will just start
>timing out and failing.  And once you've hit that point, it's very
>difficult to get back up to speed w/o recycling the app.
>
>So, potential solutions are: Get a faster CPU in server decrease tape
>mounts through new, larger drives decrease real-time load at mount times
>by decreasing number of saveset parallelisms below total available

>        - If you have 100 target sessions and you're only using 90, that
>'free' space will allow for easier mounts/dismounts stack more clients
>into a single group that uses a small saveset parallelism Make sure
>clients are labeled and empty before use.  Having the server do the
>labeling on the fly is God Awful on the system and uses MUCH more
>resources than having prelabeled tapes that just mount. OR some
>combination of the above

--
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>