> One thing though, is that you shouldn't use
> Compress Always. This can really slow things
> down.
I'm curious why you say this. COMPRESSALWAYS YES was added a while back as
a performance enhancement. If you set COMPRESSALWAYS NO, if a compressed
file grows, then the entire transaction needs to be retried, which impacts
performance.
I suppose if the file were to grow substantially, then the time it takes
to "compress" the growing file could exceed the time it would take to
retry the transaction. But I would think that would be a very rare
circumstance indeed.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: [EMAIL PROTECTED]
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Daniel Sparrman <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
01/10/2002 02:06
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: Client Compression question
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
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: [EMAIL PROTECTED]
EPIPE.COM> cc:
Sent by: Subject: Re: Client
Compression question
"ADSM: Dist
Stor Manager"
<[EMAIL PROTECTED]
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.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of
Stefan Holzwarth
Sent: Wednesday, January 09, 2002 6:56 AM
To: [EMAIL PROTECTED]
Subject: AW: Client Compression question
We are using client compression for backup of a 1,5 TByte NAS
system.(F760)
(reason is to have apparently larger disk storage pools)
Backup is done using 5 different nodes on the same machine (Dual 1 GHz
P3)
to have the opportiunity to restore with 5 sessions.
During backup i can see about 3-4 MByte per second on the network to the
TSM-server on MVS.
Restoretests for the netapp system seem to have a limit with this
compressed
data at 8-9 MB per second. (only if tapes 3590-B a filled well)
At this speed (can be observed over a longer period) TSM client and NAS
system have nearly 100% CPU load.
The data a typical userdata - many small and some large
Regards,
Stefan Holzwarth
> -----Urspr�ngliche Nachricht-----
> Von: Sotonyi Attila [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 9. Januar 2002 12:29
> An: [EMAIL PROTECTED]
> Betreff: Re: Client Compression question
>
>
> HI,
>
> With many small files this performance is not quite bad, but I think
> you should tuning you system. What kind of library you're using? Is
> compression set to enabled at drive and client level? If yes do not
> use this.
>
> �dv,
> S�tonyi Attila
mailto:[EMAIL PROTECTED]
Certified TSM 4.1 admin
M�V Informatika Kft.
Tel.:06(1)457-9372
------------------------------------------------------------
> Hi.
> I have been testing Novell backups and restores using a Compaq
proliant
8500 as
> the client
> box.
> We have been seeing ok performance of approx 10 gb an hour for backups
and
> restores,
> of 1 million objects.
> This applies both to Netware compressed and Netware uncompressed
volumes.
> However when I try TSM client compression on a backup of a netware
uncompressed
> volume, the performance drops to 1 gb. an hour.
> It is not a resource problem the compaq cpu is hardly stirring, but it
is
> definitely the TSM compression that is taking up the time (TSM tracing
shows it
> as 89% of the total time)
> I always believed in the past that slow performance with client
compression was
> down to
> lack of cpu on the client box, but there is cpu to spare with this
> configuration.
> My question is :-
> Is 1 gb an hour the best performance I that I can expect using TSM
compression
> or can anyone think of reasons why that is all I am achieving ?
> thanks
> **********************************************************************
> The information in this E-Mail is confidential and may be legally
> privileged. It may not represent the views of Scottish and Southern
> Energy plc.
> It is intended solely for the addressees. Access to this E-Mail by
> anyone else is unauthorised. If you are not the intended recipient,
> any disclosure, copying, distribution or any action taken or omitted
> to be taken in reliance on it, is prohibited and may be unlawful.
> Any unauthorised recipient should advise the sender immediately of
> the error in transmission.
> Scottish Hydro-Electric, Southern Electric, SWALEC and S+S
> are trading names of the Scottish and Southern Energy Group.
> **********************************************************************
