ADSM-L

Performance degradation when large number of filespaces in a sing le ADSM node

2000-05-07 05:25:01
Subject: Performance degradation when large number of filespaces in a sing le ADSM node
From: "Young, Chris" <YoungCS AT LOGICA DOT COM>
Date: Sun, 7 May 2000 10:25:01 +0100
We have a client using ADSM v3.1.2.  The application is an archiving
application that employs the ADSM API in a client-server mode to write data
as filespaces on an archive server within a single ADSM node.  In fact we
have a couple of nodes - one for the test system and one for live data.

We have noticed a gradual degradation of performance over the past year or
so as our archive has grown, that is in the elapsed time for a daily archive
run to a point where on some days the response time is now becoming
unacceptable (more than 12 hours).  This has been associated with days where
the "shape" of the data is such that we are creating a large number of
filespaces (several thousand) within a single archiving run.  The amount of
data isn't that great with many of these filespaces only being of the order
of say 10Kbytes in size.

Looking at the ADSM session statistics within its administration program
yields a useful clue as to what might be happening - of the order of 1000
times as much data was being sent back to the archiving client (the one that
invokes the ADSM API) as was being sent to ADSM for storage on the archive.
So if I archive a GigaByte of data in one run, I get about a Terabyte sent
back to my client !

Further investigation, and switching on ADSM client api trace options showed
what was happening.  ADSM is sending back to the client all the filespace
details in the current node on an api-call to each of:

dsmInit
dsmRegister
dsmUpdateFS

About 100 bytes of data for every filespace in the current node is being
sent back (presumably name and details info) for each of these calls.  With
the number of filespaces in our test node currently being about 5000, that
means some 0.5 Mbyte per each call to the api entry points listed above.
With tracing fully switched on each such transfer took about 20s clearly
indicating the points where the problem occurs and the data being
transferred.

This behaviour is sympathetic with our finding that archiving runs slower
when we create larger numbers of filespaces (ie make more API calls to those
particular routines above).  What's worse, is that this problem is going to
get "exponentially" worse as the archive size (ie number of filespaces in
the ADSM node) increases over time.

Our archiving client process does the following:

A. Invokes dsmInit once per type of archive data where we have about 10
types of data being archived each run.  DsmInit establishes a new ADSM
session for each such call.

B. Invokes dsmRegister once per each new filespace it creates.  For each
type of data we create a new filespace and for one particular type of bulk /
image data we create a filespace for each "image" data-file - and when there
are lots (1000s) of these this is where things start really getting slow.

C. Invokes dsmUpdateFS to correct the filespace size statistics within ADSM
for each new filespace created once we have written the data.


It is readily apparent that such an overhead adds considerably to the
processing of the archive job for all types of archive data but in
particular for bulk "image" data.  It would be reasonable to assume that the
current performance problems being experienced in archiving emanate from
this effect.

One might postulate that the ADSM client module is maintaining some form of
in-memory map of filespace information for the current node.  Why it is not
clear ?  Additionally, why does it appear to have to re-load this map
whenever the client itself updates filespace information within the node ?
This would appear to be a very inefficient and impractical implementation
and one that will yield an increasingly poor performance profile as the
number of filespaces within a single node grows, as is now the case on our
archiving systems.

Have other ADSM users (in particular direct users of the API) experienced
any similar effects ?  Is my summary of what is going on correct ?  Is this
a known feature of the ADSM product and is it being addressed in some future
release ?

Most importantly, does anyone have a work-around that might be put into
effect since we are in danger of reaching that critical crunch point where
our daily archiving run is going to exceed 24 hours ?

Many thanks

Chris Young
Senior Consultant, Logica Financial Services
5th Floor, United Kingdom House
180, Oxford Street
LONDON, UK

Tel:  +44 20 7446 4828
Email:  youngcs AT logica DOT com
<Prev in Thread] Current Thread [Next in Thread>
  • Performance degradation when large number of filespaces in a sing le ADSM node, Young, Chris <=