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
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
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
Oxford University Computing Services
Email: [EMAIL PROTECTED]
Phone: +44 (0)1865 273205 Fax:-273275
