Another simple test to do to prove to Network guys and others that TSM is not the problem is to do some FTP's from some of the clients to the TSM server. Performance here is strictly network/CPU/disk not TSM. Only exception is if you have heavy backups or restores going at the time.
David Longo >>> [EMAIL PROTECTED] 09/24/02 03:20PM >>> Check your network settings on your server. Some network cards do not Auto-negotiate with certain switches. If everything is set to Auto-negotiate, set the network card and the port of the switch it is plugged into to 100 MB/s Full duplex. I was getting the same throughput on some of my TSM servers until I did that and then I started to get 8-9 Megabyte/sec performance. Your performance may vary. Thank You, Matt Martinez Workgroup Support Analyst IDEXX Laboratories, Inc 207-856-0656 [EMAIL PROTECTED] -----Original Message----- From: Barbara Andrews [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 3:06 PM To: [EMAIL PROTECTED] Subject: HELP!... What processes can/can't run simultaneously and what throttles throughput on backup sessions ? Up until a few days ago, we were backing up only small amounts of data for several nodes each night. Then an emergency request came in to start nightly incremental backups using the TSM Domino TDP for a Domino mail server that does not do transaction logging. (Note: The Domino support staff estimates implementation of transaction logging 3-4 weeks from now.... I wish it were sooner!) All of a sudden we went from a total backup of no more than 11GB per night to more than double that, with almost 20-23 GB per night coming from that one new node alone. This node's data is sent over a 100 MB ethernet connection. Even with client compression turned on, the best throughput rate we've seen is 566 Kb/sec., and that was when the backup was run on a Sunday when there is very little activity on all systems involved (client, server, network). When other backups are running during the night, the best we've seen is 368.72 Kb/sec. This results in the backup for this one node taking at least 17 hours to run to completion. Before the addition of this new node, I had all my processes (expiration, reclamation, migration, backup storage pool) running separately and not at the same time as client backup sessions. Now we no longer have enough time in the day to do this. I need to change the way my processes run, but I have several questions I need answered before I do this. If anyone can help me with the following questions, I would appreciate it: 1) What are the implications of the process generated when I issue "backup stg backuppool offsite-pool" running at the same time that a node is currently in session backing up to the "backuppool" storage pool? 1a) Will the backup stg process finish during the node's session? 2) Do we need to be in a state where there are no active processes and/or backup/restore sessions running while the TSM database backup is running? 2a) What kind of state would the TSM database be in if it was restored from a backup that had other processes or backup/restore sessions running at the time it was taken? 3) Is there any problem with running an "expire inventory" while any of the following are running?: - a node backup session - a node restore session - migration - reclamation 4) Is there a problem running migration and reclamation at the same time if they both access the same pool? I would have thought the only problem might be a wait for a tape while one process is using it, but that this probably would only occur occasionally. I have a reclamation process running that caused a message "Removable volume 30050 is required for space reclamation." A migration process is running which requires writing to the same tape pool that 300050 is in, however 300050 displays as last being written to the day before. 5) I have very little knowledge of networking. Could someone comment on the throughput values we are seeing? Our max of 566 Kb/sec is no where near the 100 Mb/sec I have been told our ethernet connection is. "MMS <health-first.org>" made the following annotations on 09/24/2002 04:27:35 PM ------------------------------------------------------------------------------ This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ==============================================================================
