ADSM-L

Re: Searching w/inactive turned on

1996-12-17 02:42:42
Subject: Re: Searching w/inactive turned on
From: Werner Baur <Werner.Baur AT LRZ-MUENCHEN DOT DE>
Date: Tue, 17 Dec 1996 08:42:42 +0100
Our biggest node holds 2,6 million files and 125 GB of data. The server
is running on a RS6000 R24, 256 MB, ADSM 2.1.0.10. We keep two inactive
version.

Restoring or querying an active file is a matter of a few seconds.
If you try to restore an inactive file even by specifing the complete
pathname, you can go for a coffee. It takes 10 minutes to get the
selection menu.
If you try to restore inactive files by using -subdir=on or by using the
GUI, you can go for lunch. It takes more than two hours!
Don't ask what our users say to this behaviour.
Like you I am looking for workarounds. The high number of files within
one node is caused by 16,000 homedirectories of unix users within this
node.
I am thinking about splitting the homedirectories into separated
filespaces, but I am not sure about the impact of dealing with that many
filespaces.

Werner


Thomas A. La Porte wrote:
>
> I'm seeing very bad performance when searching for files to be
> restored when I am viewing both active and inactive files. I'm
> curious to know if there are problems with my configuration or if
> this performance is typical.
>
> Server: ADSM/6000 v2r1 Level 0.8 on an SP2 wide node, 256MB ram
>
> The following is the results of 'q occ' on this particular
> filespace:
>
> OSIRIS          /osiris2     3590CPOOL   1,443,285  346,581.62
>
> (yes, that's 1.4 million files, 338 GB of data)
>
> If I am searching for files to be restored (whether GUI or
> command line), with inactive files turned on, it takes
> approximately 45 minutes to build the directory tree. If I then
> change directories it takes as much as five to fifteen minutes to
> build a list of files in that directory. This makes browsing the
> directory tree of this file structure nearly impossible. Is ADSM
> not caching the initial list of files after taking 45 minutes to
> build? There is little to no problem with performance if I don't
> include inactive files, which I do not fully understand. I keep
> two inactive copies for every file, which would suggest that any
> degradation in performance should be on the order of 2x or 3x,
> not two to three *magnitudes*.
>
> Looking for any ideas on how this performance my be optimized.
>
> Thanks. -- Tom
>
> "If I could dot the 'i' in a Michigan     Thomas A. La Porte
>  game and the good lord came to take me   Archivist, Feature Animation
>  the next day ... at least I could        DreamWorks SKG
>  die happy." - Beano Cook, ESPN           <tlaporte AT anim.dreamworks DOT 
> com>

--
 ===========================================================================
 ===========================================================================
Werner Baur
Leibniz-Rechenzentrum     X.400:
S=Baur;OU=lrz;P=lrz-muenchen;A=d400;C=de
Barer Str. 21            RFC822:  Werner.Baur AT lrz DOT de
D-80333 Muenchen           Tel.:  ++49-89-28928781
Germany                     Fax:  ++49-89-2809460
 ===========================================================================
<Prev in Thread] Current Thread [Next in Thread>