Yeah, I'm leaning towards memory or maybe network right now. I'm seeing some of these during client backups: ANR0132E smnode.c(27085): Memory allocation failed: object sessP->qryBuf, size 1048576. (SESSION: 5518)
This is on a win32 system so 2GB mem is max. I'll try reducing the bufpool to give TSM some more of those gigs and doing some instrumentation for tonights backups. -km On 12/10, Lindsay Morris wrote: > I once saw this when we had set BUFPOOLSIZE way too high.Giving the TSM > server lots of memory starved the OS for memory; things slowed down horribly > until we set BUFPOOLSIZE back to the Performance-tuning-guide > recommendations ( I forget - 1/4 of available memory?) > > > On Mon, Oct 12, 2009 at 7:58 AM, km <k...@grogg.org> wrote: > > > Hello, > > > > I am currently analyzing a TSM server which uses 100% CPU on 4 cores > > when doing client backups. Almost all of it is privileged times, but > > there are very few IO's and low disk queues for both stgpools, db and log. > > > > Are there any trace flags similar to the client testflag instrument:detail > > but for the server that will allow me to see what the server is spending > > time on? > > > > I've been looking in the problem determination guide but cant find any > > flag similar to instrument_detail except for 'instr' which isnt documented > > and only gives me DB LATCHes. > > > > -km > > > > > > -- > Lindsay Morris > Principal > TSMworks > Tel. 1-859-539-9900 > lind...@tsmworks.com
