Currently, I have simply distributed the schedules for the nodes (each has
its own since the OBJECT of the schedule is the share name (e.g. "\\
rose.adm.adp.vcu.edu\healthadmin")
Traffic to/from the TSM server is not the issue. Traffic from this "head
server" to each mount point, is. Just had a long discussion with the admin
of this head/box and as I understand it, it only has 2-nics, 1-private
gigabit to the TSM backups network and 1-public gigabit connection to the
shares.
I have told them to turn on instrument tracing for a few of the nodes but I
am sure it is a network/scanning issue. One backup recently finished after
it ran *11h30m*, scanned *2M* objects of *2.2TB* but only backed up
93-files of *29MB total*.
On Mon, Aug 19, 2013 at 12:13 PM, Allen S. Rout <asr AT ufl DOT edu> wrote:
> On 08/19/2013 09:16 AM, Zoltan Forray wrote:
> > DB overhead? This is a V6.2/DB2 server. That shouldn't be an issue (or
> so
> > we are told) any more, like with 5.5? On this TSM server, the DB is a
> 245GB
> > and "Buffer pool hit ratio" is 99.3% and "Package cache hit ratio" is
> 99.7%.
> >
> > I have tried discussing things like SAN based backups and even VM imaging
> > but everyone wants access/control over their individual backups/restores
> > and thus the 31-TSM clients, yes, running 31-dsmcad sessions with unique
> > httpports
> >
>
> Well, if that's the case, how are you managing session contention? If
> you've got 31 incrementals firing "at once" (and at once could be
> pretty darn broad, if you've got millions of files) then you could
> easily swamp the machine. 12G ram is peanuts on that scale.
>
> If you specifically want them on distinct nodes, to keep access
> federated, then you're trading away the most convenient contention
> resolution tactic, which would be resourceutilization. But you know
> why you're doing it, so steam ahead.
>
>
> the next I would suggest would be:
>
> 1) sort your filesystems by how long their last incremental took.
>
> 2) round-robin them into N lists, where N starts out at, say, 3.
> Maximum pedantry would say start with one big list, so you're
> measuring them in isolation.
>
> 3) Construct scripts to run incrementals for the filesystems one at a
> time. e.g.
>
> s1.bat
>
> dsmc incr -optfile=c:\bunchofconfigbits\FS11.opt
> dsmc incr -optfile=c:\bunchofconfigbits\FS14.opt
> dsmc incr -optfile=c:\bunchofconfigbits\FS17.opt
>
> s2.bat:
>
> dsmc incr -optfile=c:\bunchofconfigbits\FS12.opt
> dsmc incr -optfile=c:\bunchofconfigbits\FS15.opt
> dsmc incr -optfile=c:\bunchofconfigbits\FS18.opt
>
>
> 4) run those batch files from e.g. windows scheduler. (or you could
> use an additional CAD instance, but...)
>
> Then repeat the analysis. Iterate, as you learn where the machine
> starts getting overloaded. Maybe it's 3 simultaneous filespaces,
> maybe others.
>
> Another rational way to order them is to make each script focus on one
> particular storage back-end. With that strategy, you'll be decreasing
> the chance that your bottleneck is in fact on one of the EMC boxen.
>
> This will require periodic attention; in your shoes, I'd write a
> script to do the analysis too, which would have as its output a dump
> of N lists of nodes, tweaked according to your evolving comprehension
> of the bottleneck.
>
>
>
>
> - Allen S. Rout
>
>
>
>
--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
|
