ADSM-L

Re: Anyone else having server database contention problems?

1998-06-04 19:18:18
Subject: Re: Anyone else having server database contention problems?
From: Trevor Foley <Trevor.Foley AT BANKERSTRUST.COM DOT AU>
Date: Fri, 5 Jun 1998 09:18:18 +1000
Hi Bill,

Are these queries and restores from the same filespace? We certainly
have contention issues on a few of our filespaces that have in excess of
4 million files on them. These particular filespaces are still on ADSM
V2.1.5.13; hoping to go to V3 within the next 10 days. We have 3
servers, 2 of which have 12 GB databases (each 80% full) and 1 21 GB
database (90% full).


Trevor
------------------------------------------------------------------------
------------------------------------------------
------------------------------------------------
Trevor Foley
Trevor Foley
Bankers Trust Australia Limited
Phone: 61-2-9259 3944    Fax: 61-2-9259 2659


        -----Original Message-----
        From:   Bill Quintrell
[SMTP:Bill_Quintrell AT PROVIDENTCOMPANIES DOT COM]
        Sent:   Friday, June 05, 1998 8:02 AM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Anyone else having server database contention
problems?

        Bill Quintrell@PROVIDENT LIFE
        06/04/98 06:01 PM
        I don't know where along the way it started happening (we have
millions of
        objects in each ADSM server)...

        Simply put, if a client issues a wildcard request against the
ADSM server,
        then other client requests are effectively locked for a
significant amount
        of time.  I am not talking about moving any data - just the
server
        searching its database.

        We have tested this on OS/390 and AIX servers with similar
results.  Its
        almost like the second and succeeding clients which need to
store an object
        (insert a record into the database) do not get a fair shot at
the server
        until the first "query" has completed.   As an example, start a
restore of
        "xxxx*" - which does not exist.  While it is running, do a store
of a
        single, small file.  It may take over 20 times longer than
normal and with
        only 2 clients and virtually no data to transmit.

        Maybe there is a server tuning knob based upon the client or
type of server
        request...

        Have you seen this?  It makes me wonder - what is the practical
limit on
        the ADSM database size for a given environment...
        (Since we use ADSM as part of our online imaging system, one
query can
        start a hundred users screaming...)
        Not to start a contest (our record is 52 hours for one
incremental backup),
        what are some of the larger ADSM server databases - i.e. number
of objects
        managed?