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