Neil,

Thanks greatly for the info and tutoral on the handles!

Yep, I agree that in summary more can be done to tune a system by proper
applications design and implementation than any systems geek can ever do to
tune it. (Speaking as an old systems geen and application designer an a
former life.)

I see IBM has a problem if they are trying to keep the same code tree for
all platforms, and I have no idea if they are or not (it makes sense to,
whenever they can... saves lots of time and money on code support).

... jack

-----Original Message-----
From: Neil Schofield [mailto:neil.schofield AT YORKSHIREWATER.CO DOT UK]
Sent: Tuesday, July 13, 2004 6:15 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM on Windows


Jack

300,000 is perfectly normal. Ours all run at over 1,000,000.

The number of handles is proportional to your database bufferpool size.
There's an IBM article about it (try
http://www-1.ibm.com/support/docview.wss?uid=swg21112140). To summarise,
each 4kb buffer pool page requires the creation of four 'conditions', and
each 'condition' requires the creation of a minimum of two Windows
'events'. Each 'event' in turn requires a handle so, doing the maths, 128Mb
of buffer pool requires a minimum of 262144 handles.

I could live with this, if it weren't for one horrendous side effect. Each
event/handle requires 64 bytes of non-paged pool memory. This is hidden in
the kernel-mode usage, rather than being visible in the non-paged pool
memory of the user-mode DSMSVC.EXE process. (For anyone familiar with
POOLMON.EXE, try enable pool tagging and monitoring the usage against the
Even pool tag as you increase the BUFPOOLSIZE parameter in TSM.)

Again doing the maths, 128Mb of buffer pool immediateley requires 16Mb of
non-paged pool memory. Now non-paged pool memory is a pretty scarce
resource in 32-bit Windows and 16Mb represents an awfully large chunk.

We first encountered this problem when configuring a two-node cluster with
each cluster node running a TSM instance using a 1Gb buffer pool. When
testing the configuration in a failover scenario with both instances
running on the same box, the system was trying to satisfy requests for
256Mb of non-paged pool memory. Windows 2000 simply can't handle this,
regardless of the physical memory configuration. This makes TSM on Windows
considerably less scalable than any other platform.

I opened a PMR, but IBM claim this is a Windows architectural limit, and
not a TSM issue. I still maintain that the problem is in the TSM design as
the likes of Microsoft (eg SQL Server) and SAP design their buffering
differently to avoid the large non-paged memory requirements. In the end,
the PMR was closed and a DCR opened instead.

My opinions only, for what they're worth.

Regards
Neil Schofield
Yorkshire Water Services Ltd.




Download walks around Yorkshire Water's reservoirs at
http://www.yorkshirewater.com/yourenjoyment/main_walk.html
The information in this e-mail is confidential and may also be legally
privileged. The contents are intended for recipient only and are subject
to the legal notice available at http://www.keldagroup.com/email.htm
Yorkshire Water Services Limited
Registered Office Western House Halifax Road Bradford BD6 2SZ
Registered in England and Wales No 2366682