ADSM-L

Re: [ADSM-L] Linux Client Performance

2007-04-05 00:56:05
Subject: Re: [ADSM-L] Linux Client Performance
From: Roger Deschner <rogerd AT UIC DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 4 Apr 2007 23:55:45 -0500
.
Look at simpler things than that, first. We have some slow Linux clients
and some fast ones.

o How much other work is the client doing during the backup? The
solution may be as simple as changing the time that it backs up.

o Be sure they are running client version 5.4. Some of the earlier Linux
client versions were terrible. Anything before V5.1 is HIGHLY suspect.

o Make sure these clients have got the latest drivers for their NIC. I
have been amazed how much of a performance difference this can make. I
had a client with old drivers who pinned and filled the server log
because they were so slow.

o Have your networking people check over the connection to be sure all
Ethernet links are full duplex.

o Pay attention to I/O tuning on the client itself. Gathering data from
all of its files and pushing them down the wire is very different from
FTP'ing a single contiguous file down that same wire. Are you dealing
with lots and lots of little files? Are your Linux filesystems
fragmented? Are these compressed filesystems? Watch top during a backup
to identify hot spots. Watch disk drive activity lights. (You can call
me insane, but I can watch top or topas for hours. It has the same
mesmerizing effect on me as watching clothes rotate in a dryer or water
flow down a river.)

o Are you using client encryption? There is a price to pay for this, and
it's entirely on the client.

o If the client has plenty of CPU cycles, consider raising the
RESOURCEUTILIZATION setting in the client options file to make it use
multiple backup sessions.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
== You are making progress when every mistake you make is a new one. ===



On Wed, 4 Apr 2007, Dave Canan wrote:

>for me to look at to help diagnose the problem here. If you want to do this
>and send it to my IBM userid below, I can see if I can give you some
>suggestions for performance improvements. To gather the trace, you need to
>place the line "testflag instrument:detail" in the dsm.sys stanza you are
>using. This will create a file named dsminstr.report.pxxx, where xxx is the
>process ID of the job. You need to do a command line backup (don't use the
>GUI), and you need to enter quit after the job before the trace is written
>out. The trace is not that large (< 1MB). If you have questions, send a
>note to my userid ddcanan AT us.ibm DOT com. Thanks.
>At 01:03 PM 4/3/2007 -0400, you wrote:
>> >> On Tue, 3 Apr 2007 16:23:43 +0100, Farren Minns <fminns AT WILEY.CO DOT 
>> >> UK> said:
>>
>>
>> > I am in the process of setting up some Linux TSM Clients at a remote
>> > site and am wondering if there are any good resources available for
>> > performance management as so far they are running painful slowly. I
>> > have tested some ftp'ing of files and these run fine.
>>
>> > Does anyone have pointers to nay good documentation that could help
>> > with this?
>>
>>
>>Especially for long distance work, make sure that all the different
>>buffers up and down the line are big enough to hold all the in-flight
>>data.  If your FTP is working well, then someone has adjusted the TCP
>>Window size, but there are buffers in the TSM server and TSM client
>>whose capacity needs to be large enough, too.
>>
>>
>>
>>- Allen S. Rout
>
>Dave Canan
>TSM Performance
>IBM Advanced Technical Support
>ddcanan AT us.ibm DOT com
>

<Prev in Thread] Current Thread [Next in Thread>