It sounds like a memory leak bug in the client.
Are you getting a 'no query restore'? This feature eliminated the need
for a large amount of client storage for a preparation phase before any
files were restored. From what you describe, I think you are doing an
nqr, which is good.
The fact that it starts quickly and runs fast and then slows down indicates
an expanding chain of control blocks which must be run to the end to
add another one for each file restored.
This sounds like a 'classic' bug, for any kind of program. You should
report this to IBM as a severity 1! (I have a large DU client too but I
haven't tested a full restore, I'm glad someone else is at this bleeding
edge!)
--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <199904291938.PAA161108 AT rigel.dartmouth DOT edu>, on 04/29/99
In <199904291938.PAA161108 AT rigel.dartmouth DOT edu>, on 04/29/99
at 03:38 PM, Pat Wilson <paw AT NORTHSTAR.DARTMOUTH DOT EDU> said:
>No, I don't think it's the OS - the file tree is fairly bushy
>(there may be 100 files in a directory, but there are many more
>directories). The restore finally failed with "out of memory"
>errors, so I think it's ADSM. Bummer.
>Is there any real technical detail on how ADSM works anywhere?
>I've been surprised to realize that, for all I _do_ know about
>ADSM, there are lots of "under the hood" questions that I can't
>seem to find detailed, authoritative answers for. Am I just not
>looking in the right places?
>Pat Wilson
>paw AT dartmouth DOT edu
>peter jodda <oelsburg AT HOTMAIL DOT COM> writes:
>> Pat Wilson wro e:
>> >I'm seeing ADSM restores of large filesystems (750,000 files) get CPU
>> bound
>> >on the client side (DU 4.0D client, ADSM v3.1.06). I think it's the
>> same
>> >problem that's been talked about several times before - once about
>> 100,000
>> >files arrive back on the client, things slow *way* down, though the
>> server
>> >is not busy. Throughput goes from 400Kb/s at the beginning to a
>> paltry
>> >50-70 Kb/s as more files are restored, and the CPU is running 70%
>> busy
>> >(doing nothing else).
>>
>> Couldn't this be a problem of the operating system or the underlaying
>> filesystem. I once created a directory with 70000 files in it.
>> Even a ls took over a minute, before any characters appeared on the
>> screen. As far as I know, the files in a directory are linked in a
>> linear list. So adding one file will lead to a scan of this list.
>> This is a quadratic effort O(n^2).
>> Because ADSM is above that filesystem, it has to wait, until the
>> filesystem operations are ready.
>>
>> How much files are in one directory?
|
