Hi,

In my experience a large DB (60GB+) needs a big DB bufferpool
in order to perform well.  We reckon on 2GB per TSM server.
There is little point in having much more than 2GB because
the server cannot use it (on AIX at least).  I believe that
as distributed the TSM server code is built to utilise only
6 segments (i.e. 1.5GB) and that limits the size of DB
bufferpool you can have.  [It can be patched for 8.]

We do experience symptoms that lead me to believe there may
well be a memory leak in the server code (we monitor the TSM
server process with xmservd and do see an ever incremental
growth of page space over time:

-----------------------------------------------------------------------
  Pid Command        Inuse      Pin     Pgsp  Virtual   64-bit    Mthrd
  Pid Command        Inuse      Pin     Pgsp  Virtual   64-bit    Mthrd
23054 ser           246422        1   131093   249423        N        Y
23054 ser           238307        1   131681   249423        N        Y

I restarted the server today at this point and it quite quickly rose
through:

33530 ser           235796        1    10896   243823        N        Y
33530 ser           235788        1    10938   243823        N        Y
33530 ser           235719        1    11013   243823        N        Y
33530 ser           223706       65    24737   244014        N        Y
33530 ser           225485        1    25070   244225        N        Y
33530 ser           224950      129    28050   244621        N        Y
33530 ser           225351        1    30650   244632        N        Y
33530 ser           231873        2    32656   244843        N        Y
33530 ser           243603        3    32836   244913        N        Y
33530 ser           248486      193    32843   245372        N        Y

(5 minute sampling).  In a couple of weeks we'll be where we were at
the retart today.

I might try again with a PMR but earlier attempts at the beginning
of the year were not very rewarding (although some small leaks were
diagnosed and fixed).

I would be interested in comments about whether my suppositions
may be correct or whether there is something I could do to rectify?
My experiences earlier in the year were that when the usage grew
much more than this the server locked up (or crashed).

Server is RS6000/H70 4cpus, 2GB, AIX 4.3.3 ML4; TSM 3.7.4.0.
DB is :

Available Assigned   Maximum   Maximum    Page     Total      Used   Pct  Max.
    Space Capacity Extension Reduction    Size    Usable     Pages  Util   Pct
     (MB)     (MB)      (MB)      (MB) (bytes)     Pages                  Util
--------- -------- --------- --------- ------- --------- --------- ----- -----
   89,936   77,672    12,264     2,736   4,096 19,884,03 16,358,36  82.3  82.3
   89,936   77,672    12,264     2,736   4,096 19,884,03 16,358,36  82.3  82.3

DB bufferpool is currently : BufPoolSize  786432

Cache hit rate is acceptable but at this DB size is not a very
meaningful metric.

A new M80 (less busy server) does not appear to have the same problem
but does have more physical memory on the box.  We have taken work
off the H70 (to the new M80) as we felt the H70 DB/server was as big
as we would like to have (although the box was capable still of more
work).

I have several theories as to the potential source of the leak
including  : reclamation (offsite particularly) or maybe client
session related - we had a server memory leak years ago related
to the the little sessions where the client asks when its next
schedule is ... and we have lots of those. [Earlier in the year
there were problems with QUERY commands - similar to SELECT].

Please write to me offline if preferred and I'll summarise back
to the list?

Thanks!
Sheelagh
--
Sheelagh Treweek
Sheelagh Treweek
Oxford University Computing Services
Email: sheelagh.treweek AT oucs.ox.ac DOT uk
Phone: +44 (0)1865 273205 Fax:-273275