Re: Tuning TSM
Yes, it is in the UNIX backup-archive client manual. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -Original Message- From: Bern Ruelas [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 5:58 PM To: [EMAIL PROTECTED] Subject: Re: Tuning TSM Hi Don, I looked for "incrbydate" in the installation guide and reference manual for this option but haven't found it. Can I use this for Solaris clients? -Bern Ruelas Cadence Design Systems - Storage Sr. Systems Engineer -Original Message- From: Don France (TSMnews) [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 2:27 PM To: [EMAIL PROTECTED] Subject: Re: Tuning TSM Reading thru this thread, no one has mentioned that backup will be slower than archive -- for TWO significant reasons: 1. The "standard" progressive-incremental requires alot of work in comparing the attributes of all files in the affected file systems, especially for a LARGE number of files/directories (whereas archive has minimal database overhead -- it just moves data). 2. Writes to disk are NOT as fast as tape IF the data can be delivered to the tape device at "streaming" speed; this is especially true if using no-RAID or RAID-5 for disk pool striping (with parity)... RAID-0 might compete if multiple paths & controllers are configured. The big advantage to disk pools is more concurrent backup/archive operations, then disk-migration can stream offload the data to tape. So, firstly, debug fundamentals using tar and archive commands (to eliminate db overhead comparing file system attributes to identify "changed" files/objects); once you are satisfied with the thruput for archive, allow 20-50% overhead for daily incremental. If your best "incremental" experience is not satisfactory, (but archive is okay) consider other options discussed in the performance-tuning papers -- such as, reducing the number of files per file system, use incrbydate during the week, increase horsepower on the client machine and/or TSM server (depending on where the incr. bottlenecks are). The SHARE archives do not yet have the Nashville proceedings posted; when they do show up, they are in the members-only area (I was just there, searching for other sessions). - Original Message - From: "Ignacio Vidal" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 17, 2002 6:30 AM Subject: Re: Tuning TSM Zlatko: OK: tcpwindowsize is in KBytes (actually my setting is 1280). I have the same question (why client is idling?). We have users working on that server from 9:00 until 22:00 (every day...), backup jobs start about 00:15/01:15 I've monitored the nodes in disk i/o operations and network transfers, in different moments of the day. About cpu load/memory usage/pagination: the values are all OK, for example: - cpu load (usr) has an average of 5~7 during all day - memory usage (have 7GB RAM) is not a problem (about 30~40% for computational the same for noncomp) - pagination: max use may be 10~12% (mostly of the day 0.5%, peaks during user's work time) Viewing your results (500GB in 3:10hs), and trying to compare: we're backing up 250GB starting 00:15 and ending 07:00... 250GB in 6:45hs (it's not good) Yesterday I set resource utilization = 10 too, and performance was the same (really a bit worst). I think there are multiple problems (and our provider -IBM- cannot help us): First of all: disk performance (IBM should tell us how to get the best from FastT500), we have from 15 to 25 MB/sec in the storage... Then: all TSM nodes in our installation have not the same file configuration. I explain a bit more this: we have nodes merging a lot of files (>25) with an average size of 40KB each and a few files (<1000) with an average size of 50MB (it's Oracle Financials: the database server keeps datafiles and files belonging to application and DB motor). We have 4 nodes such as just described, with a total of 35~40GB for each (average and growing...) Well, here was a brief description. I'm listening for new ideas. Thanks Ignacio > -Mensaje original- > De: Zlatko Krastev [mailto:[EMAIL PROTECTED]] > Enviado el: viernes, 17 de mayo de 2002 5:29 > Para: [EMAIL PROTECTED] > Asunto: Re: Tuning TSM > > > Just a point > TCPWindowsize parameter is measured in kilobytes not bytes. And > according to Administrator's reference it must be between 0 and 2048. > If not in range on client complains with ANS1036S for invalid value. > On server values out of range mean 0, i.e. OS default. > However this are side remarks. The main question is why > client is idling. > Have you monitored the node during to disk and to tape operation? Is > migration starting during backup? Are you using DIRMC. > You wrote client compression - what is the processor usage > (user)? What is > the disk load
Re: Tuning TSM
Hi Don, I looked for "incrbydate" in the installation guide and reference manual for this option but haven't found it. Can I use this for Solaris clients? -Bern Ruelas Cadence Design Systems - Storage Sr. Systems Engineer -Original Message- From: Don France (TSMnews) [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 2:27 PM To: [EMAIL PROTECTED] Subject: Re: Tuning TSM Reading thru this thread, no one has mentioned that backup will be slower than archive -- for TWO significant reasons: 1. The "standard" progressive-incremental requires alot of work in comparing the attributes of all files in the affected file systems, especially for a LARGE number of files/directories (whereas archive has minimal database overhead -- it just moves data). 2. Writes to disk are NOT as fast as tape IF the data can be delivered to the tape device at "streaming" speed; this is especially true if using no-RAID or RAID-5 for disk pool striping (with parity)... RAID-0 might compete if multiple paths & controllers are configured. The big advantage to disk pools is more concurrent backup/archive operations, then disk-migration can stream offload the data to tape. So, firstly, debug fundamentals using tar and archive commands (to eliminate db overhead comparing file system attributes to identify "changed" files/objects); once you are satisfied with the thruput for archive, allow 20-50% overhead for daily incremental. If your best "incremental" experience is not satisfactory, (but archive is okay) consider other options discussed in the performance-tuning papers -- such as, reducing the number of files per file system, use incrbydate during the week, increase horsepower on the client machine and/or TSM server (depending on where the incr. bottlenecks are). The SHARE archives do not yet have the Nashville proceedings posted; when they do show up, they are in the members-only area (I was just there, searching for other sessions). - Original Message - From: "Ignacio Vidal" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 17, 2002 6:30 AM Subject: Re: Tuning TSM Zlatko: OK: tcpwindowsize is in KBytes (actually my setting is 1280). I have the same question (why client is idling?). We have users working on that server from 9:00 until 22:00 (every day...), backup jobs start about 00:15/01:15 I've monitored the nodes in disk i/o operations and network transfers, in different moments of the day. About cpu load/memory usage/pagination: the values are all OK, for example: - cpu load (usr) has an average of 5~7 during all day - memory usage (have 7GB RAM) is not a problem (about 30~40% for computational the same for noncomp) - pagination: max use may be 10~12% (mostly of the day 0.5%, peaks during user's work time) Viewing your results (500GB in 3:10hs), and trying to compare: we're backing up 250GB starting 00:15 and ending 07:00... 250GB in 6:45hs (it's not good) Yesterday I set resource utilization = 10 too, and performance was the same (really a bit worst). I think there are multiple problems (and our provider -IBM- cannot help us): First of all: disk performance (IBM should tell us how to get the best from FastT500), we have from 15 to 25 MB/sec in the storage... Then: all TSM nodes in our installation have not the same file configuration. I explain a bit more this: we have nodes merging a lot of files (>25) with an average size of 40KB each and a few files (<1000) with an average size of 50MB (it's Oracle Financials: the database server keeps datafiles and files belonging to application and DB motor). We have 4 nodes such as just described, with a total of 35~40GB for each (average and growing...) Well, here was a brief description. I'm listening for new ideas. Thanks Ignacio > -Mensaje original- > De: Zlatko Krastev [mailto:[EMAIL PROTECTED]] > Enviado el: viernes, 17 de mayo de 2002 5:29 > Para: [EMAIL PROTECTED] > Asunto: Re: Tuning TSM > > > Just a point > TCPWindowsize parameter is measured in kilobytes not bytes. > And according > to Administrator's reference it must be between 0 and 2048. If not in > range on client complains with ANS1036S for invalid value. On server > values out of range mean 0, i.e. OS default. > However this are side remarks. The main question is why > client is idling. > Have you monitored the node during to disk and to tape operation? Is > migration starting during backup? Are you using DIRMC. > You wrote client compression - what is the processor usage > (user)? What is > the disk load - is the processor I/O wait high? Is the paging > space used - > check with svmon -P. > You should get much better results. For example recently > we've achieved > 500 GB in 3h10m - fairly good. It was similar to your config - AIX > node&server, cli
Re: Tuning TSM
Reading thru this thread, no one has mentioned that backup will be slower than archive -- for TWO significant reasons: 1. The "standard" progressive-incremental requires alot of work in comparing the attributes of all files in the affected file systems, especially for a LARGE number of files/directories (whereas archive has minimal database overhead -- it just moves data). 2. Writes to disk are NOT as fast as tape IF the data can be delivered to the tape device at "streaming" speed; this is especially true if using no-RAID or RAID-5 for disk pool striping (with parity)... RAID-0 might compete if multiple paths & controllers are configured. The big advantage to disk pools is more concurrent backup/archive operations, then disk-migration can stream offload the data to tape. So, firstly, debug fundamentals using tar and archive commands (to eliminate db overhead comparing file system attributes to identify "changed" files/objects); once you are satisfied with the thruput for archive, allow 20-50% overhead for daily incremental. If your best "incremental" experience is not satisfactory, (but archive is okay) consider other options discussed in the performance-tuning papers -- such as, reducing the number of files per file system, use incrbydate during the week, increase horsepower on the client machine and/or TSM server (depending on where the incr. bottlenecks are). The SHARE archives do not yet have the Nashville proceedings posted; when they do show up, they are in the members-only area (I was just there, searching for other sessions). - Original Message - From: "Ignacio Vidal" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 17, 2002 6:30 AM Subject: Re: Tuning TSM Zlatko: OK: tcpwindowsize is in KBytes (actually my setting is 1280). I have the same question (why client is idling?). We have users working on that server from 9:00 until 22:00 (every day...), backup jobs start about 00:15/01:15 I've monitored the nodes in disk i/o operations and network transfers, in different moments of the day. About cpu load/memory usage/pagination: the values are all OK, for example: - cpu load (usr) has an average of 5~7 during all day - memory usage (have 7GB RAM) is not a problem (about 30~40% for computational the same for noncomp) - pagination: max use may be 10~12% (mostly of the day 0.5%, peaks during user's work time) Viewing your results (500GB in 3:10hs), and trying to compare: we're backing up 250GB starting 00:15 and ending 07:00... 250GB in 6:45hs (it's not good) Yesterday I set resource utilization = 10 too, and performance was the same (really a bit worst). I think there are multiple problems (and our provider -IBM- cannot help us): First of all: disk performance (IBM should tell us how to get the best from FastT500), we have from 15 to 25 MB/sec in the storage... Then: all TSM nodes in our installation have not the same file configuration. I explain a bit more this: we have nodes merging a lot of files (>25) with an average size of 40KB each and a few files (<1000) with an average size of 50MB (it's Oracle Financials: the database server keeps datafiles and files belonging to application and DB motor). We have 4 nodes such as just described, with a total of 35~40GB for each (average and growing...) Well, here was a brief description. I'm listening for new ideas. Thanks Ignacio > -Mensaje original- > De: Zlatko Krastev [mailto:[EMAIL PROTECTED]] > Enviado el: viernes, 17 de mayo de 2002 5:29 > Para: [EMAIL PROTECTED] > Asunto: Re: Tuning TSM > > > Just a point > TCPWindowsize parameter is measured in kilobytes not bytes. > And according > to Administrator's reference it must be between 0 and 2048. If not in > range on client complains with ANS1036S for invalid value. On server > values out of range mean 0, i.e. OS default. > However this are side remarks. The main question is why > client is idling. > Have you monitored the node during to disk and to tape operation? Is > migration starting during backup? Are you using DIRMC. > You wrote client compression - what is the processor usage > (user)? What is > the disk load - is the processor I/O wait high? Is the paging > space used - > check with svmon -P. > You should get much better results. For example recently > we've achieved > 500 GB in 3h10m - fairly good. It was similar to your config - AIX > node&server, client compression, disk pool, GB ether. Ether > was driven > 10-25 MB/s depending on achieved compression. The bottleneck was EMC > Symmetrix the node was reading from but another company was > dealing with > it and we were unable to get more than 60-70 MB/s read. > Resourceutilization was set to 10. > > Zlatko Krastev > IT Consultant > > > > > Please respond to
Re: Tuning TSM
Zlatko: OK: tcpwindowsize is in KBytes (actually my setting is 1280). I have the same question (why client is idling?). We have users working on that server from 9:00 until 22:00 (every day...), backup jobs start about 00:15/01:15 I've monitored the nodes in disk i/o operations and network transfers, in different moments of the day. About cpu load/memory usage/pagination: the values are all OK, for example: - cpu load (usr) has an average of 5~7 during all day - memory usage (have 7GB RAM) is not a problem (about 30~40% for computational the same for noncomp) - pagination: max use may be 10~12% (mostly of the day 0.5%, peaks during user's work time) Viewing your results (500GB in 3:10hs), and trying to compare: we're backing up 250GB starting 00:15 and ending 07:00... 250GB in 6:45hs (it's not good) Yesterday I set resource utilization = 10 too, and performance was the same (really a bit worst). I think there are multiple problems (and our provider -IBM- cannot help us): First of all: disk performance (IBM should tell us how to get the best from FastT500), we have from 15 to 25 MB/sec in the storage... Then: all TSM nodes in our installation have not the same file configuration. I explain a bit more this: we have nodes merging a lot of files (>25) with an average size of 40KB each and a few files (<1000) with an average size of 50MB (it's Oracle Financials: the database server keeps datafiles and files belonging to application and DB motor). We have 4 nodes such as just described, with a total of 35~40GB for each (average and growing...) Well, here was a brief description. I'm listening for new ideas. Thanks Ignacio > -Mensaje original- > De: Zlatko Krastev [mailto:[EMAIL PROTECTED]] > Enviado el: viernes, 17 de mayo de 2002 5:29 > Para: [EMAIL PROTECTED] > Asunto: Re: Tuning TSM > > > Just a point > TCPWindowsize parameter is measured in kilobytes not bytes. > And according > to Administrator's reference it must be between 0 and 2048. If not in > range on client complains with ANS1036S for invalid value. On server > values out of range mean 0, i.e. OS default. > However this are side remarks. The main question is why > client is idling. > Have you monitored the node during to disk and to tape operation? Is > migration starting during backup? Are you using DIRMC. > You wrote client compression - what is the processor usage > (user)? What is > the disk load - is the processor I/O wait high? Is the paging > space used - > check with svmon -P. > You should get much better results. For example recently > we've achieved > 500 GB in 3h10m - fairly good. It was similar to your config - AIX > node&server, client compression, disk pool, GB ether. Ether > was driven > 10-25 MB/s depending on achieved compression. The bottleneck was EMC > Symmetrix the node was reading from but another company was > dealing with > it and we were unable to get more than 60-70 MB/s read. > Resourceutilization was set to 10. > > Zlatko Krastev > IT Consultant > > > > > Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > Sent by:"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > cc: > > Subject:Re: Tuning TSM > > Zlatko: > Here are the answers: > > > Have you tested what is the performance of FAStT 500 disks? > > Those were > > mid-class disk storage originally designed for PC servers > > market and later > > modified to be compatible with rs6k/pSeries. > > This is completely true: IBM installed FastT500 instead of SSA disks > (they said they were faster). > We have done a "re-cabling" of these devices, and got a better IO > balance on the controllers. > > > Try some simple tests on the TSM server when quiet: > > - 'date; dd if=/dev/zero of=/fastt_fs/test_file bs=262144 > > count=16384; > > date' to test write speed. Use large file to simulate TSM > heavy load. > > - 'date; dd if=/fastt_fs/test_file of=/dev/null' to check read speed > > In a test like you proposed, FastT500 brings a peformance of about > 60MB/sec > > > Also check your Gb Ether - are you using Jumbo frames, have > > you enabled in > > AIX 'no -o rfc1323=1', what are send&receive bufsizes, what is > > TCPWindowsize of TSM server&client. Have you measured > > LAN&disk load during > > backup? > > Yes, we're using this parameters: > > tcp_sendspace = 1048576 > tcp_recvspace = 1048576 > udp_sendspace = 64000 > udp_recvspace = 64000 > rfc1323
Re: Tuning TSM
Just a point TCPWindowsize parameter is measured in kilobytes not bytes. And according to Administrator's reference it must be between 0 and 2048. If not in range on client complains with ANS1036S for invalid value. On server values out of range mean 0, i.e. OS default. However this are side remarks. The main question is why client is idling. Have you monitored the node during to disk and to tape operation? Is migration starting during backup? Are you using DIRMC. You wrote client compression - what is the processor usage (user)? What is the disk load - is the processor I/O wait high? Is the paging space used - check with svmon -P. You should get much better results. For example recently we've achieved 500 GB in 3h10m - fairly good. It was similar to your config - AIX node&server, client compression, disk pool, GB ether. Ether was driven 10-25 MB/s depending on achieved compression. The bottleneck was EMC Symmetrix the node was reading from but another company was dealing with it and we were unable to get more than 60-70 MB/s read. Resourceutilization was set to 10. Zlatko Krastev IT Consultant Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by:"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject:Re: Tuning TSM Zlatko: Here are the answers: > Have you tested what is the performance of FAStT 500 disks? > Those were > mid-class disk storage originally designed for PC servers > market and later > modified to be compatible with rs6k/pSeries. This is completely true: IBM installed FastT500 instead of SSA disks (they said they were faster). We have done a "re-cabling" of these devices, and got a better IO balance on the controllers. > Try some simple tests on the TSM server when quiet: > - 'date; dd if=/dev/zero of=/fastt_fs/test_file bs=262144 > count=16384; > date' to test write speed. Use large file to simulate TSM heavy load. > - 'date; dd if=/fastt_fs/test_file of=/dev/null' to check read speed In a test like you proposed, FastT500 brings a peformance of about 60MB/sec > Also check your Gb Ether - are you using Jumbo frames, have > you enabled in > AIX 'no -o rfc1323=1', what are send&receive bufsizes, what is > TCPWindowsize of TSM server&client. Have you measured > LAN&disk load during > backup? Yes, we're using this parameters: tcp_sendspace = 1048576 tcp_recvspace = 1048576 udp_sendspace = 64000 udp_recvspace = 64000 rfc1323 = 1 TCPWindowsize 1310720 What I've observed is that during a client backup session, TSM seems to be idled for a long time (and the server machine has not constraint problems for memory or I/O) I can send other data. Thank you all. Ignacio > > Zlatko Krastev > IT Consultant > > > > Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > Sent by:"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > cc: > > Subject:Tuning TSM > > Hi: > I'm managing a pretty small TSM installation with 4 RS/6K machines (2 > 6M1 and 2 6H1) running AIX 4.3.3 (ML9). > TSM software consists of the server (running in a 6M1 - 7Gb RAM), and > the clients running in the same machine and on the others. > > I´ve got the following situation: > - the total of data backed up is about 200Gb's, > - 4 servers are connected using gigabit ethernet links (and > have 6Gb RAM > and 7Gb RAM each model 6H1 and 6M1 respectively) > - TSM uses a storage pool of 240Gb on FastT500 disks (those are > connected by FC channels) > - TSM uses a 3581 library (LTO) with 1 drive, > > The fact is (for the same set of information): > When I do an archive backup operation with TSM, the time > elapsed rounds > 5 hours (TSM writes "right to" the tape). > When I do an incremental backup operation, TSM uses about > 6:30hs for it > (TSM writes to storage pool). > > I'm looking for a rational approach to solve this "problem": isn't it > more fast writing to storage pool (disk) that to tape? > > Anyone had the same performance problem? > > Is it really a performance problem? > > I would like some commentaries about this, I can provide some > info about > the configuration of TSM and the AIX servers. > > Regards > > Ignacio >
Re: Tuning TSM
Look at the proceedings at www.share.org from the Nashville Meeting. A
couple TSM sessions given by Charlie Nichols from the TSM Performance Lab
has everything you need (5722 and 5723).
Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180
-Original Message-
From: Bill Boyer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 16, 2002 9:34 AM
To: [EMAIL PROTECTED]
Subject: Re: Tuning TSM
Great for AIX, but does anyone have IP tuning parameters for Windows2000?
Bill Boyer
DSS, Inc.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of lt
Sent: Wednesday, May 15, 2002 6:42 PM
To: [EMAIL PROTECTED]
Subject: Re: Tuning TSM
Hi,
Be sure to set "ALL" parameters for the nic cards correctly to match the
ports on the switches. Ensure that "ALL" 'no options' are set correctly for
your environment.
Example:
AIX 433_ML_08:
100MB ethernet nic cards have the xmit/recieve buffer pools maxed out
100MB ethernet nic cards have the speed/duplex set to match switch ports
'no options' are set via an /etc/rc.{filename} & called via /etc/inittab
via:
rctunenet:2:wait:/etc/rc.tunenet > /dev/console 2>&1 #Tune Network Parms
example:
/etc/rc.tunenet
if [ -f /usr/sbin/no ]
then
thewall=$(/usr/sbin/no -o thewall | awk '{ print $3 }')
if [ $thewall -lt 4096 ]
then
/usr/sbin/no -d thewall
else
print thewall is set to $thewall - left as is
fi
/usr/sbin/no -d thewall
/usr/sbin/no -d sb_max
/usr/sbin/no -o tcp_sendspace=$thewall
/usr/sbin/no -o tcp_recvspace=$thewall
/usr/sbin/no -o udp_sendspace=64000
/usr/sbin/no -o udp_recvspace=64000
/usr/sbin/no -o net_malloc_police=32768
/usr/sbin/no -o tcp_mssdflt=1452
/usr/sbin/no -o ipqmaxlen=150
/usr/sbin/no -o rfc1323=1
fi
print "Network parameters tuned..."
By allowing AIX_ML_08 to "figure out" the best settings for thewall/sb_max,
no -d thewall/sb_max, I do not have to go thru the issue of calculating it
anymore!!! Having gone thru the above scenario, my 100MB ethernet cloud
performs at, a minimum, 10MB/sec. A lot of the network traffic is logged at:
11MB/sec. We are now implementing a GIG ethernet network and I am looking
forward to working with it as well.
HTH.
Mr. Lindsey Thomson
BLDG:042/2F-065 IMA: 0422F065
11400 Burnet Rd., Austin, TX 78758
off) 512) 823 6522 / (TL) 793 6522
"I never waste memory on things that can easily be stored
and retrieved from elsewhere."- Albert Einstein
"Blessed is the nation whose God is the Lord" - Psalm 33:12 "Time is a great
teacher, but unfortunately it kills all
its pupils"- Hector Berloiz
On Wed, 15 May 2002, Ignacio Vidal wrote:
> Hi:
> I'm managing a pretty small TSM installation with 4 RS/6K machines (2
> 6M1 and 2 6H1) running AIX 4.3.3 (ML9). TSM software consists of the
> server (running in a 6M1 - 7Gb RAM), and the clients running in the
> same machine and on the others.
>
> I4ve got the following situation:
> - the total of data backed up is about 200Gb's,
> - 4 servers are connected using gigabit ethernet links (and have 6Gb
> RAM and 7Gb RAM each model 6H1 and 6M1 respectively)
> - TSM uses a storage pool of 240Gb on FastT500 disks (those are
> connected by FC channels)
> - TSM uses a 3581 library (LTO) with 1 drive,
>
> The fact is (for the same set of information):
> When I do an archive backup operation with TSM, the time elapsed
> rounds 5 hours (TSM writes "right to" the tape). When I do an
> incremental backup operation, TSM uses about 6:30hs for it (TSM writes
> to storage pool).
>
> I'm looking for a rational approach to solve this "problem": isn't it
> more fast writing to storage pool (disk) that to tape?
>
> Anyone had the same performance problem?
>
> Is it really a performance problem?
>
> I would like some commentaries about this, I can provide some info
> about the configuration of TSM and the AIX servers.
>
> Regards
>
> Ignacio
>
Re: Tuning TSM
Dwight: LTO is performing good enough (for us), and we only have 1 drive. I was reading all hints exposed in the list, many of them have been implemented during last 2 months. We're using a disk storage pool, client compression, etc. I realize that we can explore a bit more resourceutilization parameter... Thanks Ignacio > -Mensaje original- > De: Cook, Dwight E [mailto:[EMAIL PROTECTED]] > Enviado el: jueves, 16 de mayo de 2002 9:43 > Para: [EMAIL PROTECTED] > Asunto: Re: Tuning TSM > > > Run multiple concurrent client sessions... > Run with TSM client compression... > Go to disk first (to help facilitate the multiple concurrent > sessions seeing > how you only have one drive)... > Get another drive ! ! ! (will really help when you have to > run reclamation) > I'm partial to 3590's but lots of folks are running LTO's > for backups, look into resourceutilization > for archives, just fire off multiple, if backing up a large DB run 25+ > concurrently > we archive a 3.1 TB SAP data base in 20 hours running 25 > concurrent sessions > with TSM client compression (compresses the info down to > about 800 GB) and > back over 100 Mb/sec fast ethernet (@ 40 GB/hr) across GigE > we run about 70 > GB/hr so do the same work in just 12 hours (or so)... > > > just my 2 cents worth > > Dwight > > > > -Original Message- > From: Ignacio Vidal [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 15, 2002 4:50 PM > To: [EMAIL PROTECTED] > Subject: Tuning TSM > > > Hi: > I'm managing a pretty small TSM installation with 4 RS/6K machines (2 > 6M1 and 2 6H1) running AIX 4.3.3 (ML9). > TSM software consists of the server (running in a 6M1 - 7Gb RAM), and > the clients running in the same machine and on the others. > > I´ve got the following situation: > - the total of data backed up is about 200Gb's, > - 4 servers are connected using gigabit ethernet links (and > have 6Gb RAM > and 7Gb RAM each model 6H1 and 6M1 respectively) > - TSM uses a storage pool of 240Gb on FastT500 disks (those are > connected by FC channels) > - TSM uses a 3581 library (LTO) with 1 drive, > > The fact is (for the same set of information): > When I do an archive backup operation with TSM, the time > elapsed rounds > 5 hours (TSM writes "right to" the tape). > When I do an incremental backup operation, TSM uses about > 6:30hs for it > (TSM writes to storage pool). > > I'm looking for a rational approach to solve this "problem": isn't it > more fast writing to storage pool (disk) that to tape? > > Anyone had the same performance problem? > > Is it really a performance problem? > > I would like some commentaries about this, I can provide some > info about > the configuration of TSM and the AIX servers. > > Regards > > Ignacio >
Re: Tuning TSM
Great for AIX, but does anyone have IP tuning parameters for Windows2000?
Bill Boyer
DSS, Inc.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
lt
Sent: Wednesday, May 15, 2002 6:42 PM
To: [EMAIL PROTECTED]
Subject: Re: Tuning TSM
Hi,
Be sure to set "ALL" parameters for the nic cards correctly to match the
ports on the switches.
Ensure that "ALL" 'no options' are set correctly for your environment.
Example:
AIX 433_ML_08:
100MB ethernet nic cards have the xmit/recieve buffer pools maxed out
100MB ethernet nic cards have the speed/duplex set to match switch ports
'no options' are set via an /etc/rc.{filename} & called via
/etc/inittab via:
rctunenet:2:wait:/etc/rc.tunenet > /dev/console 2>&1 #Tune Network Parms
example:
/etc/rc.tunenet
if [ -f /usr/sbin/no ]
then
thewall=$(/usr/sbin/no -o thewall | awk '{ print $3 }')
if [ $thewall -lt 4096 ]
then
/usr/sbin/no -d thewall
else
print thewall is set to $thewall - left as is
fi
/usr/sbin/no -d thewall
/usr/sbin/no -d sb_max
/usr/sbin/no -o tcp_sendspace=$thewall
/usr/sbin/no -o tcp_recvspace=$thewall
/usr/sbin/no -o udp_sendspace=64000
/usr/sbin/no -o udp_recvspace=64000
/usr/sbin/no -o net_malloc_police=32768
/usr/sbin/no -o tcp_mssdflt=1452
/usr/sbin/no -o ipqmaxlen=150
/usr/sbin/no -o rfc1323=1
fi
print "Network parameters tuned..."
By allowing AIX_ML_08 to "figure out" the best settings for
thewall/sb_max, no -d thewall/sb_max, I do not have to go thru the issue
of calculating it anymore!!!
Having gone thru the above scenario, my 100MB ethernet cloud performs
at, a minimum, 10MB/sec. A lot of the network traffic is logged at:
11MB/sec.
We are now implementing a GIG ethernet network and I am looking forward
to working with it as well.
HTH.
Mr. Lindsey Thomson
BLDG:042/2F-065 IMA: 0422F065
11400 Burnet Rd., Austin, TX 78758
off) 512) 823 6522 / (TL) 793 6522
"I never waste memory on things that can easily be stored
and retrieved from elsewhere."- Albert Einstein
"Blessed is the nation whose God is the Lord" - Psalm 33:12
"Time is a great teacher, but unfortunately it kills all
its pupils"- Hector Berloiz
On Wed, 15 May 2002, Ignacio Vidal wrote:
> Hi:
> I'm managing a pretty small TSM installation with 4 RS/6K machines (2
> 6M1 and 2 6H1) running AIX 4.3.3 (ML9).
> TSM software consists of the server (running in a 6M1 - 7Gb RAM), and
> the clients running in the same machine and on the others.
>
> I4ve got the following situation:
> - the total of data backed up is about 200Gb's,
> - 4 servers are connected using gigabit ethernet links (and have 6Gb RAM
> and 7Gb RAM each model 6H1 and 6M1 respectively)
> - TSM uses a storage pool of 240Gb on FastT500 disks (those are
> connected by FC channels)
> - TSM uses a 3581 library (LTO) with 1 drive,
>
> The fact is (for the same set of information):
> When I do an archive backup operation with TSM, the time elapsed rounds
> 5 hours (TSM writes "right to" the tape).
> When I do an incremental backup operation, TSM uses about 6:30hs for it
> (TSM writes to storage pool).
>
> I'm looking for a rational approach to solve this "problem": isn't it
> more fast writing to storage pool (disk) that to tape?
>
> Anyone had the same performance problem?
>
> Is it really a performance problem?
>
> I would like some commentaries about this, I can provide some info about
> the configuration of TSM and the AIX servers.
>
> Regards
>
> Ignacio
>
Re: Tuning TSM
Run multiple concurrent client sessions... Run with TSM client compression... Go to disk first (to help facilitate the multiple concurrent sessions seeing how you only have one drive)... Get another drive ! ! ! (will really help when you have to run reclamation) I'm partial to 3590's but lots of folks are running LTO's for backups, look into resourceutilization for archives, just fire off multiple, if backing up a large DB run 25+ concurrently we archive a 3.1 TB SAP data base in 20 hours running 25 concurrent sessions with TSM client compression (compresses the info down to about 800 GB) and back over 100 Mb/sec fast ethernet (@ 40 GB/hr) across GigE we run about 70 GB/hr so do the same work in just 12 hours (or so)... just my 2 cents worth Dwight -Original Message- From: Ignacio Vidal [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 15, 2002 4:50 PM To: [EMAIL PROTECTED] Subject: Tuning TSM Hi: I'm managing a pretty small TSM installation with 4 RS/6K machines (2 6M1 and 2 6H1) running AIX 4.3.3 (ML9). TSM software consists of the server (running in a 6M1 - 7Gb RAM), and the clients running in the same machine and on the others. I´ve got the following situation: - the total of data backed up is about 200Gb's, - 4 servers are connected using gigabit ethernet links (and have 6Gb RAM and 7Gb RAM each model 6H1 and 6M1 respectively) - TSM uses a storage pool of 240Gb on FastT500 disks (those are connected by FC channels) - TSM uses a 3581 library (LTO) with 1 drive, The fact is (for the same set of information): When I do an archive backup operation with TSM, the time elapsed rounds 5 hours (TSM writes "right to" the tape). When I do an incremental backup operation, TSM uses about 6:30hs for it (TSM writes to storage pool). I'm looking for a rational approach to solve this "problem": isn't it more fast writing to storage pool (disk) that to tape? Anyone had the same performance problem? Is it really a performance problem? I would like some commentaries about this, I can provide some info about the configuration of TSM and the AIX servers. Regards Ignacio
Re: Tuning TSM
Hello Ignacio,
I had performance problems with TSM too. (I still have
in another installation too :p) ... After fixing the
networks problems (to 100/full duplex) performance
was still poor.
I don't know what version you are using but in my case
I had to change the TCPWINDOWSIZE in the client
options file to 63 (default is 32) , and now I'm
backing up 11 GB in 1 hour which is pretty good ...
Hope it helps
Sandra
--- Ignacio Vidal <[EMAIL PROTECTED]> wrote:
> Lindsey:
> I've been walking around once and again about
> networking configuration,
> then with disk i/o performance, then with how is
> configurated on disk
> the storage pool (if it was in raid 5, or in raid 1
> or in raid 10...).
>
> Those servers are connected through gigabit ethernet
> channels, and they
> are offering from 50 to 75 MBytes/sec. I believe
> that throughput is very
> low, but Tivoli's people (here) insisted in other
> factors (disk i/o,
> configuration of raids, etc)
>
> I'll try your reccomendation, I have not all
> neccesary values from our
> switches now.
> Thanks
>
> Ignacio
>
> > -Mensaje original-
> > De: lt [mailto:[EMAIL PROTECTED]]
> > Enviado el: Miircoles, 15 de Mayo de 2002 19:42
> > Para: [EMAIL PROTECTED]
> > Asunto: Re: Tuning TSM
> >
> >
> > Hi,
> > Be sure to set "ALL" parameters for the nic cards
> correctly
> > to match the
> > ports on the switches.
> > Ensure that "ALL" 'no options' are set correctly
> for your
> > environment.
> >
> > Example:
> > AIX 433_ML_08:
> > 100MB ethernet nic cards have the xmit/recieve
> buffer pools
> > maxed out
> > 100MB ethernet nic cards have the speed/duplex
> set to match
> > switch ports
> > 'no options' are set via an /etc/rc.{filename} &
> called via
> > /etc/inittab via:
> > rctunenet:2:wait:/etc/rc.tunenet > /dev/console
> 2>&1 #Tune
> > Network Parms
> >example:
> > /etc/rc.tunenet
> > if [ -f /usr/sbin/no ]
> > then
> > thewall=$(/usr/sbin/no -o thewall | awk '{
> print $3 }')
> > if [ $thewall -lt 4096 ]
> > then
> > /usr/sbin/no -d thewall
> > else
> > print thewall is set to $thewall - left as is
> > fi
> > /usr/sbin/no -d thewall
> > /usr/sbin/no -d sb_max
> > /usr/sbin/no -o tcp_sendspace=$thewall
> > /usr/sbin/no -o tcp_recvspace=$thewall
> > /usr/sbin/no -o udp_sendspace=64000
> > /usr/sbin/no -o udp_recvspace=64000
> > /usr/sbin/no -o net_malloc_police=32768
> > /usr/sbin/no -o tcp_mssdflt=1452
> > /usr/sbin/no -o ipqmaxlen=150
> > /usr/sbin/no -o rfc1323=1
> > fi
> > print "Network parameters tuned..."
> > By allowing AIX_ML_08 to "figure out" the best
> settings for
> > thewall/sb_max, no -d thewall/sb_max, I do not
> have to go
> > thru the issue
> > of calculating it anymore!!!
> > Having gone thru the above scenario, my 100MB
> ethernet cloud
> > performs
> > at, a minimum, 10MB/sec. A lot of the network
> traffic is logged at:
> > 11MB/sec.
> > We are now implementing a GIG ethernet network
> and I am
> > looking forward
> > to working with it as well.
> >
> > HTH.
> >
> >
> > Mr. Lindsey Thomson
> > BLDG:042/2F-065 IMA: 0422F065
> > 11400 Burnet Rd., Austin, TX 78758
> > off) 512) 823 6522 / (TL) 793 6522
> >
> > "I never waste memory on things that can easily be
> stored
> > and retrieved from elsewhere."- Albert
> Einstein
> > "Blessed is the nation whose God is the Lord" -
> Psalm 33:12
> > "Time is a great teacher, but unfortunately it
> kills all
> > its pupils"- Hector Berloiz
> >
> > On Wed, 15 May 2002, Ignacio Vidal wrote:
> >
> > > Hi:
> > > I'm managing a pretty small TSM installation
> with 4 RS/6K
> > machines (2
> > > 6M1 and 2 6H1) running AIX 4.3.3 (ML9).
> > > TSM software consists of the server (running in
> a 6M1 - 7Gb
> > RAM), and
> > > the clients running in the same machine and on
> the others.
> > >
> > > I4ve got the following situation:
> > > - the total of data backed up is about 200Gb's,
> > > - 4 servers are connected using gigabit ethernet
> links (and
> > have 6Gb RAM
> > > and 7Gb RAM each model 6H1 and 6M1 respectively)
> > > - T
Re: Tuning TSM
Lindsey:
I've been walking around once and again about networking configuration,
then with disk i/o performance, then with how is configurated on disk
the storage pool (if it was in raid 5, or in raid 1 or in raid 10...).
Those servers are connected through gigabit ethernet channels, and they
are offering from 50 to 75 MBytes/sec. I believe that throughput is very
low, but Tivoli's people (here) insisted in other factors (disk i/o,
configuration of raids, etc)
I'll try your reccomendation, I have not all neccesary values from our
switches now.
Thanks
Ignacio
> -Mensaje original-
> De: lt [mailto:[EMAIL PROTECTED]]
> Enviado el: Miércoles, 15 de Mayo de 2002 19:42
> Para: [EMAIL PROTECTED]
> Asunto: Re: Tuning TSM
>
>
> Hi,
> Be sure to set "ALL" parameters for the nic cards correctly
> to match the
> ports on the switches.
> Ensure that "ALL" 'no options' are set correctly for your
> environment.
>
> Example:
> AIX 433_ML_08:
> 100MB ethernet nic cards have the xmit/recieve buffer pools
> maxed out
> 100MB ethernet nic cards have the speed/duplex set to match
> switch ports
> 'no options' are set via an /etc/rc.{filename} & called via
> /etc/inittab via:
> rctunenet:2:wait:/etc/rc.tunenet > /dev/console 2>&1 #Tune
> Network Parms
>example:
> /etc/rc.tunenet
> if [ -f /usr/sbin/no ]
> then
> thewall=$(/usr/sbin/no -o thewall | awk '{ print $3 }')
> if [ $thewall -lt 4096 ]
> then
> /usr/sbin/no -d thewall
> else
> print thewall is set to $thewall - left as is
> fi
> /usr/sbin/no -d thewall
> /usr/sbin/no -d sb_max
> /usr/sbin/no -o tcp_sendspace=$thewall
> /usr/sbin/no -o tcp_recvspace=$thewall
> /usr/sbin/no -o udp_sendspace=64000
> /usr/sbin/no -o udp_recvspace=64000
> /usr/sbin/no -o net_malloc_police=32768
> /usr/sbin/no -o tcp_mssdflt=1452
> /usr/sbin/no -o ipqmaxlen=150
> /usr/sbin/no -o rfc1323=1
> fi
> print "Network parameters tuned..."
> By allowing AIX_ML_08 to "figure out" the best settings for
> thewall/sb_max, no -d thewall/sb_max, I do not have to go
> thru the issue
> of calculating it anymore!!!
> Having gone thru the above scenario, my 100MB ethernet cloud
> performs
> at, a minimum, 10MB/sec. A lot of the network traffic is logged at:
> 11MB/sec.
> We are now implementing a GIG ethernet network and I am
> looking forward
> to working with it as well.
>
> HTH.
>
>
> Mr. Lindsey Thomson
> BLDG:042/2F-065 IMA: 0422F065
> 11400 Burnet Rd., Austin, TX 78758
> off) 512) 823 6522 / (TL) 793 6522
>
> "I never waste memory on things that can easily be stored
> and retrieved from elsewhere."- Albert Einstein
> "Blessed is the nation whose God is the Lord" - Psalm 33:12
> "Time is a great teacher, but unfortunately it kills all
> its pupils"- Hector Berloiz
>
> On Wed, 15 May 2002, Ignacio Vidal wrote:
>
> > Hi:
> > I'm managing a pretty small TSM installation with 4 RS/6K
> machines (2
> > 6M1 and 2 6H1) running AIX 4.3.3 (ML9).
> > TSM software consists of the server (running in a 6M1 - 7Gb
> RAM), and
> > the clients running in the same machine and on the others.
> >
> > I´ve got the following situation:
> > - the total of data backed up is about 200Gb's,
> > - 4 servers are connected using gigabit ethernet links (and
> have 6Gb RAM
> > and 7Gb RAM each model 6H1 and 6M1 respectively)
> > - TSM uses a storage pool of 240Gb on FastT500 disks (those are
> > connected by FC channels)
> > - TSM uses a 3581 library (LTO) with 1 drive,
> >
> > The fact is (for the same set of information):
> > When I do an archive backup operation with TSM, the time
> elapsed rounds
> > 5 hours (TSM writes "right to" the tape).
> > When I do an incremental backup operation, TSM uses about
> 6:30hs for it
> > (TSM writes to storage pool).
> >
> > I'm looking for a rational approach to solve this
> "problem": isn't it
> > more fast writing to storage pool (disk) that to tape?
> >
> > Anyone had the same performance problem?
> >
> > Is it really a performance problem?
> >
> > I would like some commentaries about this, I can provide
> some info about
> > the configuration of TSM and the AIX servers.
> >
> > Regards
> >
> > Ignacio
> >
>
Re: Tuning TSM
Hi,
Be sure to set "ALL" parameters for the nic cards correctly to match the
ports on the switches.
Ensure that "ALL" 'no options' are set correctly for your environment.
Example:
AIX 433_ML_08:
100MB ethernet nic cards have the xmit/recieve buffer pools maxed out
100MB ethernet nic cards have the speed/duplex set to match switch ports
'no options' are set via an /etc/rc.{filename} & called via
/etc/inittab via:
rctunenet:2:wait:/etc/rc.tunenet > /dev/console 2>&1 #Tune Network Parms
example:
/etc/rc.tunenet
if [ -f /usr/sbin/no ]
then
thewall=$(/usr/sbin/no -o thewall | awk '{ print $3 }')
if [ $thewall -lt 4096 ]
then
/usr/sbin/no -d thewall
else
print thewall is set to $thewall - left as is
fi
/usr/sbin/no -d thewall
/usr/sbin/no -d sb_max
/usr/sbin/no -o tcp_sendspace=$thewall
/usr/sbin/no -o tcp_recvspace=$thewall
/usr/sbin/no -o udp_sendspace=64000
/usr/sbin/no -o udp_recvspace=64000
/usr/sbin/no -o net_malloc_police=32768
/usr/sbin/no -o tcp_mssdflt=1452
/usr/sbin/no -o ipqmaxlen=150
/usr/sbin/no -o rfc1323=1
fi
print "Network parameters tuned..."
By allowing AIX_ML_08 to "figure out" the best settings for
thewall/sb_max, no -d thewall/sb_max, I do not have to go thru the issue
of calculating it anymore!!!
Having gone thru the above scenario, my 100MB ethernet cloud performs
at, a minimum, 10MB/sec. A lot of the network traffic is logged at:
11MB/sec.
We are now implementing a GIG ethernet network and I am looking forward
to working with it as well.
HTH.
Mr. Lindsey Thomson
BLDG:042/2F-065 IMA: 0422F065
11400 Burnet Rd., Austin, TX 78758
off) 512) 823 6522 / (TL) 793 6522
"I never waste memory on things that can easily be stored
and retrieved from elsewhere."- Albert Einstein
"Blessed is the nation whose God is the Lord" - Psalm 33:12
"Time is a great teacher, but unfortunately it kills all
its pupils"- Hector Berloiz
On Wed, 15 May 2002, Ignacio Vidal wrote:
> Hi:
> I'm managing a pretty small TSM installation with 4 RS/6K machines (2
> 6M1 and 2 6H1) running AIX 4.3.3 (ML9).
> TSM software consists of the server (running in a 6M1 - 7Gb RAM), and
> the clients running in the same machine and on the others.
>
> I´ve got the following situation:
> - the total of data backed up is about 200Gb's,
> - 4 servers are connected using gigabit ethernet links (and have 6Gb RAM
> and 7Gb RAM each model 6H1 and 6M1 respectively)
> - TSM uses a storage pool of 240Gb on FastT500 disks (those are
> connected by FC channels)
> - TSM uses a 3581 library (LTO) with 1 drive,
>
> The fact is (for the same set of information):
> When I do an archive backup operation with TSM, the time elapsed rounds
> 5 hours (TSM writes "right to" the tape).
> When I do an incremental backup operation, TSM uses about 6:30hs for it
> (TSM writes to storage pool).
>
> I'm looking for a rational approach to solve this "problem": isn't it
> more fast writing to storage pool (disk) that to tape?
>
> Anyone had the same performance problem?
>
> Is it really a performance problem?
>
> I would like some commentaries about this, I can provide some info about
> the configuration of TSM and the AIX servers.
>
> Regards
>
> Ignacio
>
