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 <a...@ufl.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 zfor...@vcu.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