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
