Hi
Normally, with powerful servers, the impact of compression wouldn't be that
much.
Client compression means you put a lot of load on the client, because it
has to do the compression.
With a P3 1Ghz machine, this impact shouldn't be noticable. We're running
50 servers with client compression, and we're having about 6-7 MB/s on a
100MB/s ethernet. Thats the Network Throughput.
What you should look for is also the Aggregate Data Rate. Normally, the
Network Throughput is just how fast your LAN is. But with compression
enabled, the data throughput should be greater than the Network Throughput.
One thing though, is that you shouldn't use Compress Always. This can
really slow things down.
Another thing to look at his to see if your clients are optimized.
Normally, the later TSM clients have good performance, thought client
before 4.2.1.15 has had bad perfomance.
Therefore, take a look at your options file, and upgrade the clients to
4.2.1.15 or 4.2.1.18. This should increase your performance.
Best Regards
Daniel Sparrman
-----------------------------------
Daniel Sparrman
Daniel Sparrman
Exist i Stockholm AB
Bergkällavägen 31D
192 79 SOLLENTUNA
Växel: 08 - 754 98 00
Mobil: 070 - 399 27 51
Kevin
<kevin@STORAG To: ADSM-L AT VM.MARIST DOT EDU
EPIPE.COM> cc:
Sent by: Subject: Re: Client Compression
question
"ADSM: Dist
Stor Manager"
<ADSM-L AT VM DOT MA
RIST.EDU>
2002-01-09
21:11
Please
respond to
"ADSM: Dist
Stor Manager"
Hi Stefan,
Using compression will really slow down the backup - mostly in backup
mode, but in restore as well. If you set the format parameter in the
device class to drive (instead of a fixed number) you will get both the
benefit of a dynamic device class with regard to number of drives (for
additional drive installations and drive failure(s)) and you will enable
automatic hardware compression. This compression is better than the
software based compression, however when the system is queried, the
number returned will reflect raw data sizes, not compressed data sizes.
Client side (software based) compression or server side (software based
compression) will work in conjunction with library based hardware
compression however you will not receive any compression benefit by
running both and the numbers returned upon query will not reflect the
actual size of data on the tape. In some cases an already compressed
file has taken 15 minutes while software based compression tried to
re-compress it. The impact is not small.
Remember, this is based on the device class specification of
format=drive, and may not be applicable to all drives, but only those
with compression capabilities. We currently use LTO based native fiber
drives.
Choosing one method of compression over the other will improve
performance and specifying hardware compression while forcing off
software compression should really improve performance.
Another neat performance tuning trick (as I'm sure you already know) is
to backup to a hard drive initially, and then force migration (set the
pool to migrate hi=0 lo=0 in a script, and then set it back to normal
again after an hour or so) to de-stage the data off the hard disk and
onto tape. This allows multiple sessions (sessions are not limited to
number of available tape drives) and hard disk is generally faster as a
storage pool.
Let me know if this helps,
Kevin.
|
