ADSM-L

Re: TCP/IP communications failure

1997-01-13 13:46:19
Subject: Re: TCP/IP communications failure
From: Hans Beierle <hbeier01 AT DE.EDS DOT COM>
Date: Mon, 13 Jan 1997 10:46:19 -0800
Detlev Hilberg wrote:
>
> Hi,
>
> have you tried to do an 'ls -l' in that directory and measure the
> time it took for the command to end successfully?
> We once had a user which has had over 30.000 (!) Files in one directory
> (also scientists can be crazy, eh ?)
> 'ls -l' took a long time to return. In the mean time adsm hitted his
> default timeout limits and crashed the whole session on this
> client. After increasing
>
> *   COMMTimeout
> *
> *   Specifies the communication timeout value in seconds.
> *
>
> and
>
> *   ********************************************************************
> *   IDLETimeout
> *
> *   Specifies the number of minutes that a client session can be idle
> *   before its session will be canceled.
> *
>
> in dsmserv.opt to much more higher values we succeeded to back up the
> filesystem.
>
> Could be the reason for your successes on retry, as the client get
> the filesys data from the fast file buffer memory pools instead  of the
> slow disk drives.
>
> It was just an idea ... ;-)
>
> Bye,
> /dh
>
> --
> Detlev Hilberg                                     hilberg AT 
> rz.uni-frankfurt DOT de
> Hochschulrechenzentrum der Johann Wolfgang Goethe-Universitaet  Frankfurt/Main
> Office phone: +49 69 798-28005,  fax: -28313,  priv. cellular: +49 171 4702196

We have applications building up directories with 50000+ files and
encountered due to this size also various timeout problems during backup
runs. Same as others did, we fixed that by increasing COMMTimeout. Yet,
I'm concerned about having to change a general option which applies
to all client/server sessions to address a problem which relates only
to some few clients. The install manual states about COMMTimeout:
"The server terminates the session to release communication resources as
soon as possible, and to ensure that database locks are not held for
undue periods of time."
So, I assume that COMMTimeout should be as low as possible. To get around
these long running directory scans, the ADSM client should have a kind of
'heartbeat' function, which tells the server that it's still alive.


--
/----------------------------------------------------------------\
/----------------------------------------------------------------\
| Hans Beierle                      Internet: hbeier AT eds DOT de      |
| EDS Informationstechnologie       Voice: ++49 6142 803170      |
| und Service (Deutschland) GmbH    FAX:   ++49 6142 803030      |
| Eisenstr. 56 (N15)                                             |
| D-65428 Ruesselsheim, Germany                                  |
\----------------------------------------------------------------/
<Prev in Thread] Current Thread [Next in Thread>