In most environments I have experienced, the backups are usually run at
non-app time. I have even seen some environments that have a Gigabyte
Network exclusively for Backups. Here the SP-switch during the day is used
(a little) for the apps, but during the night it is exclusively for the
Frame backups. Out of our 100 clients about 3-5 are development, leaving
95-100 production all run at night during non-app times. I had some Tivoli
consultants try to match the 264 GB an hour SP-switch speed and on one of
the nodes they did accomplish 300 GB an hour speed, but that was with 5
threads of 60 GB an hour speed. On other nodes the speed would only go as
fast as the node could push. Other factors were file size (smaller files
take longer), and how many and how big the CPU's. I just recently restored
a 200 GB database (during production time) in 2 1/2 hours. The DBA had
done it before in 8-10 hours (single threaded), but I had her brake the
threads down into 6 separate restores and the M80 and the GB copper handled
fine.
Thank You,
Bill Rosette
Data Center/IS/Papa Johns International
WWJD
"Dearman,
Richard" To: ADSM-L AT VM.MARIST
DOT EDU
<rdearm1 AT UIC DOT EDU> cc:
Sent by: "ADSM: Subject: Re: Gigabit Ethernet
speed
Dist Stor
Manager"
<[email protected]
.EDU>
12/30/2002 10:46
AM
Please respond to
"ADSM: Dist Stor
Manager"
It could help but like I said most clients aren't tuned for optimum backup
performance. Meaning the disk configuration strategy is't setup for
optimum
reads and it cann't keep up with gig speeds. If the client is a production
server then not only is it processing the backup, it has to do whatever it
was built for as well. So you have two applications battling for resources
at the client. The tsm server only has one thing going on an thats
backups.
If you change resource utilization you could get some jump in throughput
but
at the same time the other app running on that client will suffer. Is it
really worth it? Maybe in your environment but thats your call.
-----Original Message-----
From: William Rosette [mailto:Bill_Rosette AT PAPAJOHNS DOT COM]
Sent: Monday, December 30, 2002 9:24 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Gigabit Ethernet speed
What about upping the RESOURCEUTILIZATION? Will this not increase through
put?
Thank You,
Bill Rosette
Data Center/IS/Papa Johns International
WWJD
"Dearman,
Richard" To:
ADSM-L AT VM.MARIST DOT EDU
<rdearm1 AT UIC DOT EDU> cc:
Sent by: "ADSM: Subject: Re: Gigabit
Ethernet speed
Dist Stor
Manager"
<[email protected]
.EDU>
12/30/2002 10:27
AM
Please respond to
"ADSM: Dist Stor
Manager"
If you use Jumbo Frames at the client, tsm server and switches. You will
see a higher through put with a lot less cpu utilization. I my experience
the biggest problem with backup speed is the client is the bottle neck.
Either it cann't read from its disk fast enough to support gig speeds or
the
client cpu cann't process the data fast enough. Usually with a P660 with
4x750's processors, and multiple HBA's connected to your SAN that tsm
server
won't be the problem.
-----Original Message-----
From: Antonio J Pires [mailto:antoniopires AT PT.IBM DOT COM]
Sent: Monday, December 30, 2002 5:43 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Gigabit Ethernet speed
Hi,
Can we use 2 or more gigabit interfaces to increase backup bandwidth?
Any experience on this approach?
Thanks in advance,
António Pires
"Seay, Paul"
<seay_pd@NAPTHEON To:
ADSM-L AT VM.MARIST DOT EDU
.COM> cc:
Sent by: "ADSM: Subject: Re: Gigabit
Ethernet speed
Dist Stor
Manager"
<[email protected]
.EDU>
28-12-2002 08:36
Please respond to
"ADSM: Dist Stor
Manager"
I agree. However, to my knowledge that is either the default for the P660
offering or there is no way to set it. We use hardware on our Windows
machines. Even then, you have to process the packet queues and when moving
70MB/sec of 1500 byte packets, it takes some resources.
Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-----Original Message-----
From: Rushforth, Tim [mailto:TRushfor AT CITY.WINNIPEG.MB DOT CA]
Sent: Friday, December 27, 2002 8:27 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Gigabit Ethernet speed
Consider using NIC's with TCP Offload Engines (TOE'S)- this should help
with
CPU utilization.
-----Original Message-----
From: Seay, Paul [mailto:seay_pd AT NAPTHEON DOT COM]
Sent: December 27, 2002 2:53 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Gigabit Ethernet speed
For some reason we forget that IP packet processing on the client and
server
take a lot of CPU resources. Check your CPU utilization on both to see
what
is happening. My experience is a 450mhz x 4 P660 can process maximum of
about 70000 kb/sec. When we had only one gigabit interface that is what it
ran at and also with 2 gigabit interfaces in total. In both cases the CPU
goes to 100 percent and no more packets can be processed.
It can also be a client issue if they do not have enough CPU to push the
data to the server.
This is the place LANFREE comes into play.
Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-----Original Message-----
From: Conko, Steven [mailto:sconko AT ADT DOT COM]
Sent: Tuesday, December 24, 2002 9:44 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Gigabit Ethernet speed
anybody have any tips on what type of "Network transfer rate" we should be
seeing for our backups over gigabit ethernet? the clients backup via copper
Gb ethernet dedicated for backups to a tsm server connected to a 3494 tape
library with 10 3590 tape drives via fibre channel/brocade switch.
there is only one client on one gigabit interface and 3 on another.
any tips for improving network performance?
thanks
Steven A. Conko
Senior Unix Systems Administrator
ADT Security Services, Inc.
***************************EMAIL DISCLAIMER*************************** This
email and any files transmitted with it may be confidential and are
intended
solely for the use of th individual or entity to whom they are addressed.
If you are not the intended recipient or the individual responsible for
delivering the e-mail to the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is strictly prohibited. If you have received this e-mail in error, please
delete it and notify the sender or contact Health Information Management
312.996.3941.
***************************EMAIL DISCLAIMER*************************** This
email and any files transmitted with it may be confidential and are
intended
solely for the use of th individual or entity to whom they are addressed.
If you are not the intended recipient or the individual responsible for
delivering the e-mail to the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is strictly prohibited. If you have received this e-mail in error, please
delete it and notify the sender or contact Health Information Management
312.996.3941.
|
