ADSM-L

Re: HELP!... What processes can/can't run simultaneously and what throttles throughput on backup sessions ?

2002-09-24 15:23:15
Subject: Re: HELP!... What processes can/can't run simultaneously and what throttles throughput on backup sessions ?
From: "Martinez, Matt" <matt AT IDEXX DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 24 Sep 2002 15:20:29 -0400
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
matt AT idexx DOT com

 -----Original Message-----
From:   Barbara Andrews [mailto:BAndrews AT ERIE1.WNYRIC DOT ORG]
Sent:   Tuesday, September 24, 2002 3:06 PM
To:     ADSM-L AT VM.MARIST DOT EDU
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.