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 <km AT grogg DOT 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
> lindsay AT tsmworks DOT com