ADSM-L

Re: TSM on Windows

2004-07-13 19:21:34
Subject: Re: TSM on Windows
From: Neil Schofield <neil.schofield AT YORKSHIREWATER.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 14 Jul 2004 00:15:22 +0100
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

<Prev in Thread] Current Thread [Next in Thread>