I saw this statement also in the 4.1.2.12 readme, but have been unable to
find anything on what the problem was. I would be interested reading about
this. Is the IC29444 referring to an APAR or some other document? I have
access to the Tivoli Knowledge Base, but can't find a hit doing a search on
that number.
Anne Short
Lockheed Martin Enterprise Information Systems
Gaithersburg, Maryland
301-240-6184
CODA/I Storage Management
-----Original Message-----
From: Tim Williams [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 11:40 AM
To: [EMAIL PROTECTED]
Subject: Re: Backing up directories with 600K files
Jerry,
I ran into something similar in the last couple weeks. I was running a NT4
server with 2.3 Million files and it was taking 13 hours to back up. The
root of the problem was actually the TSM client code I had recently applied
on the machine (TSM 3.7.2.18)
In the 4.1.2.12 remade there is a comment :
* IC29444 PERFORMANCE PROBLEM DURING BACKUP WHEN ANTI VIRUS
*
* SOFTWARE IS ACTIVE.
We upgraded to 4.1.2.12 and it now backs up in 4 hours.
-Tim Williams
[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]
Sent: Wednesday, March 21, 2001 7:48 AM
To: [EMAIL PROTECTED]
Subject: Backing up directories with 600K files
Date: March 21, 2001 Time: 8:23 AM
From: Jerry Lawson
The Hartford Insurance Group
860 547-2960 [EMAIL PROTECTED]
----------------------------------------------------------------------------
-
I know I have seen this question on the list a long time ago, but I can't
remember any specifics on potential solutions. Perhaps someone who has lost
fewer brain cells than I have can be of help....
I have a customer who has a large number of small files on a server, and is
seeing long processing times. He is running the SIEBEL Help desk
applications, and ultimately will have 1.5 million files on the server. The
test he ran included about 600K files, totaling 5GB of space. Obviously,
the individual files are not very big (he says 12K is typical. They are
already compressed, so we have compression turned off for this client.
The backup was initiated from a command line, and took something like 8
hours to complete. In the past he has been getting something like
2.5GB/hour throughput, so there is most likely not a network problem here.
Unfortunately, he did not pipe the output to a file, so I have no log of
what he did. I am speculating that he spent most of the time processing the
directory entries. (I am led to believe that the files are in a relatively
small number of sub-directory entries.)
The customer box is NT4, our server is OS/390. Both the client and the
server are running TSM 3.7
Has anyone had similar experiences, or suggestions about how to speed up
processing?
----------------------------------------------------------------------------
-
Jerry
Insanity is doing the same thing over and over....and expecting the results
to be different - Anon.
