No, the Netware client in question is on a pretty fast storrage array.
Disk I/O on the
client appears moderate during the backup. From the Netware performance
numbers it
appears to be some bottleneck/limit in the Networker client or the TCP/IP
setup on the client.
It also appears that the Networker 4.15 Netware client uses only 1 CPU even
if multiple CPUs
exists.. Perhaps a CPU limit?
Robert Maiello
Thomson Healthcare
-----Original Message-----
From: John Gowing [mailto:johng AT sourceconsulting.co DOT za]
Sent: Friday, May 30, 2003 3:40 AM
To: Legato NetWorker discussion; Robert Maiello
Subject: Re: [Networker] netware client perfromance problems
Hi, I've just joined and so have not followed this entire thread, but maybe
this will provide food for thought.
1. Disk drive read performance. In these days of >15MBsec tape drives
(SDLT,LTO) the tape write performance easily exceeds the sustained read
capability of a single disk drive, currently in the order of 7-10MBsec for a
high performance drive. So you must provide disk arrays if you need to keep
a tape drive streaming.
2. I don't remember the details but I am prety sure that Networker is clever
enough to understand the disk/volume relationships of the sources. It will
not allow multiple savestreams from a single disk device. Again arrays are
the answer.
3. There are a number of Disk performance tools available, use one that
reads your disk and throws the data stream to measure absolute read
performance.
John Gowing Source Consulting
From: "Robert Maiello" <robert.maiello AT MEDEC DOT COM>
> I'd have to concur with what Tim's stated here.. We did break out our
> large Netware box into 2 clients. We listed the top level directories in
> the volume (there was only 1 big volume) as savesets of each client. We
> did setup directives much like Andrew suggested where the one client still
> included the top level volume but skipped all the subdirectories. The
> directives and this technique work well for getting multiple streams from
> a netware box. Each client runs at a seperate time from a different
group.
>
> Unfortunately, the performance stays flat ..about 5 to 7 MB/sec.. even
going
> gigabit to gigabit and using SDLT drives.
>
> Robert Maiello
> Thomson Healthcare
>
>
>
>
> On Wed, 28 May 2003 23:17:24 -0500, Tim Mooney
> <mooney AT DOGBERT.CC.NDSU.NODAK DOT EDU> wrote:
>
> >In regard to: [Networker] netware client perfromance problems,
Brendan...:
> >
> >>CLIENT: Netware 6, Client version 4.21 (the latest I could find)
> >>I have a problem with the speed of the backups of one of our netware
> >>servers. It doesn't ever seem to go above 3-5 mb/second on 100baseT
full
> >>duplex (both cards and switches have been checked). All of our netware
> >>clients get this sort of speed, so I believe that it is something to do
> >>with the client itself. This is the same even on gigabit interfaces.
> >>Tapes used are LTO.
> >
> >[...]
> >
> >>The problem I have is that I need more speed. There is a 260GB used
(out
> >>of about 320GB) partition that takes about 18hours to back up. The
> >>problem is that the netware client is significantly different to the
other
> >>clients.
> >>Things that I've investigated so far to get multiple save streams
> >>Guess what, no command line save.
> >>I then thought I'd use save from the server. Can't do. The netware
> >>client requires a username and password which there isn't an option for
in
> >>the command line.
> >>I then thought I'd try using a wild card in the client definition -
> >>doesn't work.
> >
> >I can commisserate. We're getting larger and larger Netware volumes, and
> >3-5 MB/s is the best we see too, also with a dedicated 100 full-duplex
> >network and gigabit on the server.
> >
> >>My question is, how can I get multiple save streams from the netware box
> >>without having to type in individual directory paths. Individual
> >>directory paths is not a suitable option as it is at the level where
> >>someone may just add another one & not tell the backup administrator so
it
> >>needs to be a scripted solution.
> >
> >Splitting the client into multiple clients and not using "All" for most
of
> >them is the only way to do it that anyone has offered. I haven't gone
> >that route yet, but I will likely be doing so soon.
> >
> >The good news is that Andrew McGeorge posted a *great* trick a few weeks
> >back that can be used to mitigate the issue that you (and others, myself
> >included) have with clients that don't use the "All" saveset. You're
> >exactly right that it makes it *way* too easy for new volumes and folders
> >to get missed, but Andrew's tip provides a workaround. Search the
> >archives for posts by him, and look for one regarding "Large SAN".
> >
> >Beyond that, Tarjei's response indicates the level of support Legato
> >normally gives Netware. There are *many* improvements that could and
> >should be made to the Netware client, but because Netware is not as
> >high-demand as other platforms and because it's significantly different
> >from other platforms, Legato apparently feels that it's not worth their
> >RoI to improve the client.
> >
> >There was a thread several months back involving NetWare, where someone
> >from Legato support had apparently told someone on the list (I forget
who,
> >but I could probably dig it up) that part of the problem has to do with
> >the number of files that get backed up by a particular instance of a
> >client. I'm still a little vague on what was being said and what the
> >limit was as far as # of files, but apparently keeping each instance of
> >a client below so many files also will be important for sustained backup
> >speed.
> >
> >Good luck!
> >
> >Tim
> >--
> >Tim Mooney mooney AT dogbert.cc.ndsu.NoDak DOT
> >edu
> >Information Technology Services (701) 231-1076 (Voice)
> >Room 242-J6, IACC Building (701) 231-8541 (Fax)
> >North Dakota State University, Fargo, ND 58105-5164
> >
> >--
> >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.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service.
________________________________________________________________________
________________________________________________________________________
The information contained in this communication may be confidential or legally
privileged and is intended only for the recipient named above. If the reader of
this message is not the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this communication or its contents is
strictly prohibited. If you have received this communication in error, please
immediately advise the sender and delete the original and any copies from your
computer system.
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
