Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Networker 6.1.2 any experience???
- Thread starter nepomuk
- Start date
Otrebor5665
Technical User
We have updated our Legato NetWorker server two days ago first impression is that work properly better then rel 6.1.1.
Our server is tru64 cluster with 25 client connected accross fibre channel.
Before upgrade to 6.1.2 we have a lot o problem about usage of cpu fron nsrd process(most of time near 100%) graphical interfare become very slowly, many backup stay in pendig without any active session.
Since two days we not have this problem we hope well for the future
Our server is tru64 cluster with 25 client connected accross fibre channel.
Before upgrade to 6.1.2 we have a lot o problem about usage of cpu fron nsrd process(most of time near 100%) graphical interfare become very slowly, many backup stay in pendig without any active session.
Since two days we not have this problem we hope well for the future
We have upgraded to 6.1.2 and now have almost 100% failure rate with out Netware servers:
* nwfsops002
ATA: RPC error, Unable to send
* nwfsops002ATA: (201) DATA: hplgm1
* nwfsops002ATA: Sat Jul 6 02:37:14 2002: rcmdsrv nlm
* nwfsops002ATA: can't end rec 1
* nwfsops002
ATA: RPC error, Unable to send* nwfsops002
ATA: (201) DATA: hplgm1* nwfsops002
ATA: Sat Jul 6 02:37:14 2002: rcmdsrv nlm* nwfsops002
ATA: can't end rec 1dave4real,
What Netware OS version are your running and what Netware
Legato client version?
I've had 6.1.2 running on a smaller server without issue
for the last 2 weeks. Our larger server backs up Netware
client though and this worries me. Did you reconnect from
the Netwares client after the upgrade?
Very scary.
rmaiello
What Netware OS version are your running and what Netware
Legato client version?
I've had 6.1.2 running on a smaller server without issue
for the last 2 weeks. Our larger server backs up Netware
client though and this worries me. Did you reconnect from
the Netwares client after the upgrade?
Very scary.
rmaiello
To dave4real,
I had the very same error messaages from networker 6.0.2 during netware backups to a win 2k server. Turned out to be netware clients timing out when they didnt have access to a tape drive. Within the edit device menu there is a "save mount timeout" setting which defaults at 30 mins. Changing this to 60 mins means that your netware savesets will wait twice as long before timing out. That and running netware separately and making groups smaller - staggering start times fixed the problem - 100% success.
I had the very same error messaages from networker 6.0.2 during netware backups to a win 2k server. Turned out to be netware clients timing out when they didnt have access to a tape drive. Within the edit device menu there is a "save mount timeout" setting which defaults at 30 mins. Changing this to 60 mins means that your netware savesets will wait twice as long before timing out. That and running netware separately and making groups smaller - staggering start times fixed the problem - 100% success.
to ooodeano
But why does this happen - I have experienced networker 6.1.2 or 6.1.1 to react very slow to nsrjb commands and to nsradmin. Far slower than 6.0. Any explanation for that?
If you have a time of about 10 to 20 minutes from a tape request to the actual mount you surely get timeouts, even if the networker is not under high load.
by the way I have seen that nsrd and nsrmmd run with nice level -20. Renicing them did not help, as they reniced back to -20 soon thereafter.
Johanes
But why does this happen - I have experienced networker 6.1.2 or 6.1.1 to react very slow to nsrjb commands and to nsradmin. Far slower than 6.0. Any explanation for that?
If you have a time of about 10 to 20 minutes from a tape request to the actual mount you surely get timeouts, even if the networker is not under high load.
by the way I have seen that nsrd and nsrmmd run with nice level -20. Renicing them did not help, as they reniced back to -20 soon thereafter.
Johanes
Hi,
found a propable memory leak in nsrexecd. Our machine ran out of swap space - memory: 2Gb, swap: 2GB. So backups stopped. Having problems with recycling of tapes and the GUI is way too slow...
Overall I would not recommend upgrading. Wait til Legato publishes patches or 6.1.3 (with new bugs)
Johanes
found a propable memory leak in nsrexecd. Our machine ran out of swap space - memory: 2Gb, swap: 2GB. So backups stopped. Having problems with recycling of tapes and the GUI is way too slow...
Overall I would not recommend upgrading. Wait til Legato publishes patches or 6.1.3 (with new bugs)
Johanes
I have lost much sleep over 6.12 we reverted back to 6.11 now I can sleep again. Main issue nsrd chokes itself out of resources and hangs. Also the bug fix for nsrim was not incorporated so that compounded problems. Legato is calling 6.12 a success. I say the king has no clothes.
joe
joe
I upgrade from 5.5.3 to 6.1.1 and then to 6.1.2
I have exprience of the GUI hanging and it looks like the nsrd and nsrmmd processes chew more cpu than before. Backups still run ok but I have upgraded all 200+ clients to the latest client install so maybe that helps.
One thing I have noticed is that to do a directive restore the client machine seems to have to be an administrative user. This wasn't like that on 5.5.3 you only had to setup the restore server to be on the client's remote access list.
just my 2p worth
Paul
I have exprience of the GUI hanging and it looks like the nsrd and nsrmmd processes chew more cpu than before. Backups still run ok but I have upgraded all 200+ clients to the latest client install so maybe that helps.
One thing I have noticed is that to do a directive restore the client machine seems to have to be an administrative user. This wasn't like that on 5.5.3 you only had to setup the restore server to be on the client's remote access list.
just my 2p worth
Paul
I am running on Solaris and moved from 5.1 to 5.5.1 to 6.0.1 to 6.1.1 (with special patches to minumize nsrjb core dumping) to 6.1.2 (with a workaround job). I probably shouldn't put this in writing, but I am now content with 6.1.2.
6.1.2 experience and needed workaround
---------------------------------------
I too noticed that under 6.1.2, nsrd could be a resource hog and at times would bog the system down to no end. I found the speciifc issue to be the automated running of "nsrck -MX" by Legato networker. Specifically, I determined that if "nsrck -MX is running" and backups or other processes are started the system will grind to a halt. The solution is controlling the runnning of "nsrck -MX" to times when system is idel.
From what I have been able to determine, "nsrck -MX" runs following savesets if the last touch of /nsr/mm/nsrim.prv is more than 24 hours. Ours happen to be running just after our first backups heading into the evening and could impact all the backups that followed. Now, we don't allow it run on during full backups on the weekends and have it run after all backups on weekdays. To accomplish this the following script runs on SAT. twice, once at 7am and again at 9am.
#!/bin/sh
#
# nsrck_skip.sh
#
# This script touches the /nsr/mm/snsrim.prv file
#
# This script is run on weekedns to avoid running nsrck -MX.
#
##############################################################################
#*******************************************************************************
# Modification History:
# Date By Description
# ======= ================== =================================================
# 01Dec01 Jim Taylor Initial script.
#*******************************************************************************
touch /nsr/mm/nsrim.prv
echo "done"
# End of script
My support vendor, Datalink provided following info:
Solution Title: Purpose of nsrck -MX
Solution ID: legato8902
Here is the solution:
The "M" means it's running in Master mode. In other words, it's been called by nsrd or another NetWorker daemon and it logs information into the daemon.log
The "X" is equivalent to -L3. It cross checks the index entries with the
media database and compresses and deletes redundant records, thus keeping the index sizes down.
Moreover, the nsrim.prv file present under /nsr/mm directory is used to determine if an index check is done or not. nsrd checks this file occasionally to see if it is over 24 hrs old. If so, a check is performed.
6.1.2 experience and needed workaround
---------------------------------------
I too noticed that under 6.1.2, nsrd could be a resource hog and at times would bog the system down to no end. I found the speciifc issue to be the automated running of "nsrck -MX" by Legato networker. Specifically, I determined that if "nsrck -MX is running" and backups or other processes are started the system will grind to a halt. The solution is controlling the runnning of "nsrck -MX" to times when system is idel.
From what I have been able to determine, "nsrck -MX" runs following savesets if the last touch of /nsr/mm/nsrim.prv is more than 24 hours. Ours happen to be running just after our first backups heading into the evening and could impact all the backups that followed. Now, we don't allow it run on during full backups on the weekends and have it run after all backups on weekdays. To accomplish this the following script runs on SAT. twice, once at 7am and again at 9am.
#!/bin/sh
#
# nsrck_skip.sh
#
# This script touches the /nsr/mm/snsrim.prv file
#
# This script is run on weekedns to avoid running nsrck -MX.
#
##############################################################################
#*******************************************************************************
# Modification History:
# Date By Description
# ======= ================== =================================================
# 01Dec01 Jim Taylor Initial script.
#*******************************************************************************
touch /nsr/mm/nsrim.prv
echo "done"
# End of script
My support vendor, Datalink provided following info:
Solution Title: Purpose of nsrck -MX
Solution ID: legato8902
Here is the solution:
The "M" means it's running in Master mode. In other words, it's been called by nsrd or another NetWorker daemon and it logs information into the daemon.log
The "X" is equivalent to -L3. It cross checks the index entries with the
media database and compresses and deletes redundant records, thus keeping the index sizes down.
Moreover, the nsrim.prv file present under /nsr/mm directory is used to determine if an index check is done or not. nsrd checks this file occasionally to see if it is over 24 hrs old. If so, a check is performed.
- Status
Similar threads