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: [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen S. Rout Sent: Monday, September 11, 2006 10:38 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Gig utilization during backups >> On Fri, 8 Sep 2006 09:49:56 -0700, "Gill, Geoffrey L." <[EMAIL PROTECTED]> 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