A lot of discussion around the problem is also the subject of a separate
email. In those I have mentioned hardware information. As of this time I
have changed nothing on this new system as I want to gather as much
information as possible before making a decision on what I should do. Most
everything I have compared on these systems has revealed nothing as they are
almost identical.

The basic hardware on both of these systems is the same. The real difference
lies in a few minor things. Physical memory on the old box was 5GB this new
one 4GB. Two more CPU's on the new system. The underlying disk
infrastructure is the same on both systems. The new system has more disks,
but according to what I've read not even close to the recommended limit.

The real difference is, and I see you mentioned it below, is the number of
db volumes per disk on the new system. This is something I've been looking
at changing as I feel it is more than likely part of the problem.

I know there aren't many specifics here but I guarantee that if I ever get
this worked out I will detail what I have and what I did.

Thanks,

Geoff Gill
TSM Administrator
PeopleSoft Sr. Systems Administrator
SAIC M/S-G1b
(858)826-4062
Email: geoffrey.l.gill AT saic DOT com



-----Original Message-----
From: owner-adsm-l AT VM.MARIST DOT EDU [mailto:owner-adsm-l AT VM.MARIST DOT 
EDU] On
Behalf Of Allen S. Rout
Sent: Monday, September 11, 2006 10:38 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Gig utilization during backups

>> On Fri, 8 Sep 2006 09:49:56 -0700, "Gill, Geoffrey L."
<GEOFFREY.L.GILL AT SAIC DOT COM> said:


> I'd like to get some input on what others see on their port
> utilization during heavy network traffic. With 350+ systems backing
> up to a single TSM server I'm curious as to why we see only about
> 50% utilization on the GIG port with max scheduled sessions set to
> 95. Sessions run extremely long compared to when they were on the
> old system.


You've gotten several data points about GigE utilization; but they
mostly told you what you already knew: your network can go faster than
that.

What are _all_ the changes you made between the old system and the
new?  What is the disk topology underneath?  What is the database
topology?

In a nutshell, where do you see the bottleneck being now?

CPUs approach irrelevance when your big job is I/O.  What are the two
hardware platforms?  How many adapters, attached to how many disks?
Different types?  Same?


My knee-jerk suggestion is "Database commit contention".  When folks
move up in hardware, they often "optimize" their database on newer
bigger disk, which can lead to too few DB volumes to keep up with the
transaction rates to which they're accustomed.


But that's a wild-ass guess, because we don't know much about your
system.



- Allen S. Rout