**** [POSIBLE SPAM] ****[DB2-L] WLM-adresspaces uses to much storage

Jose Ramon Vazquez

**** [POSIBLE SPAM] ****[DB2-L] WLM-adresspaces uses to much storage
Hi,

Are you creating your stored procedures with STAY RESIDENT YES ?

We have one WLM address-space with 100 MB.

Regards.







Para
[login to unmask email]
Steurs cc
Patrick
<Patrick.Steu Asunto
[login to unmask email]> **** [POSIBLE SPAM] ****[DB2-L]
Enviado por: WLM-adresspaces uses to much
DB2 Data Base storage
Discussion
List
<[login to unmask email]
2-L.ORG>


08/01/2007
09:57 AM


Por favor,
responda a
DB2 Database
Discussion
list at IDUG
<[login to unmask email]
UGDB2-L.ORG>






Hi,

We are using z/Os 1.5 and DB2 v7.1

I have a problem with one of our WLM-adressspaces. When this adresspace
starts , it uses a fairly small amount of storage ( a few Megabytes ).
But after a while it starts to grow until we ( sometimes ) get a
storage problem. At certain moments, one of these adresspaces reaches
more than 200 Megabytes of storage. All of our WLM-adressspaces have
been created with the same parameters, though I have only a problem with
the WLM-adressspaces of one specific db2. Has anyone an idea ?


greetings,
Patrick Steurs


Dba at Central Bank of Belgium
Nbb - Sydsdb
Tel : 02/2215384
NBB-DB2 intranet site ( NBB-internal use only )












Visit our website! http://www.nbb.be

"DISCLAIMER: The content of this e-mail message should not be
construed as binding on the part of the National Bank of Belgium
(NBB) unless otherwise and previously stated. The opinions
expressed in this message are solely those of the author and do not
necessarily reflect NBB viewpoints, particularly when the content
of this message, or part thereof, is private by nature or does not
fall within the professional scope of its author."


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm





------------------------------------------------------------------------------------------------

AVISO LEGAL : Este mensaje, su contenido y cualquier fichero transmitido
con él está dirigido únicamente a su destinatario y es confidencial. Por
ello se informa, a quien lo reciba por error o tenga conocimiento del mismo
sin ser su destinatario, que la información contenida en él es reservada y
su uso no autorizado, por lo que en tal caso le rogamos nos lo comunique
por la misma vía o por teléfono (+ 34 976 71 87 50), así como que se
abstenga de reproducir el mensaje mediante cualquier medio o remitirlo o
entregarlo a otra persona, procediendo a su borrado de manera inmediata.
ATCA A.I.E. se reserva las acciones legales que correspondan contra todo
tercero que acceda de forma ilegítima al contenido de cualquier mensaje
externo procedente del mismo.
------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Jose Ramon Vazquez

Fw: [DB2-L] WLM-adresspaces uses to much storage
(in response to Jose Ramon Vazquez)
Hi,

Are you creating your stored procedures with STAY RESIDENT YES ?

We have one WLM address-space with 100 MB.

Regards.







Para
[login to unmask email]
Steurs cc
Patrick
<Patrick.Steu Asunto
[login to unmask email]> [DB2-L] WLM-adresspaces uses to
Enviado por: much storage
DB2 Data Base
Discussion
List
<[login to unmask email]
2-L.ORG>


08/01/2007
09:57 AM


Por favor,
responda a
DB2 Database
Discussion
list at IDUG
<[login to unmask email]
UGDB2-L.ORG>






Hi,

We are using z/Os 1.5 and DB2 v7.1

I have a problem with one of our WLM-adressspaces. When this adresspace
starts , it uses a fairly small amount of storage ( a few Megabytes ).
But after a while it starts to grow until we ( sometimes ) get a
storage problem. At certain moments, one of these adresspaces reaches
more than 200 Megabytes of storage. All of our WLM-adressspaces have
been created with the same parameters, though I have only a problem with
the WLM-adressspaces of one specific db2. Has anyone an idea ?


greetings,
Patrick Steurs


Dba at Central Bank of Belgium
Nbb - Sydsdb
Tel : 02/2215384
NBB-DB2 intranet site ( NBB-internal use only )












Visit our website! http://www.nbb.be

"DISCLAIMER: The content of this e-mail message should not be
construed as binding on the part of the National Bank of Belgium
(NBB) unless otherwise and previously stated. The opinions
expressed in this message are solely those of the author and do not
necessarily reflect NBB viewpoints, particularly when the content
of this message, or part thereof, is private by nature or does not
fall within the professional scope of its author."


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm





------------------------------------------------------------------------------------------------

AVISO LEGAL : Este mensaje, su contenido y cualquier fichero transmitido
con él está dirigido únicamente a su destinatario y es confidencial. Por
ello se informa, a quien lo reciba por error o tenga conocimiento del mismo
sin ser su destinatario, que la información contenida en él es reservada y
su uso no autorizado, por lo que en tal caso le rogamos nos lo comunique
por la misma vía o por teléfono (+ 34 976 71 87 50), así como que se
abstenga de reproducir el mensaje mediante cualquier medio o remitirlo o
entregarlo a otra persona, procediendo a su borrado de manera inmediata.
ATCA A.I.E. se reserva las acciones legales que correspondan contra todo
tercero que acceda de forma ilegítima al contenido de cualquier mensaje
externo procedente del mismo.
------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Martin Packer

WLM-adresspaces uses to much storage
(in response to Jose Ramon Vazquez)
First, let's be careful NOT to implicate WLM too much - not that anyone has
so far. :-)

I think it's worthwhile to tease out a few points about how this works.
These are points I expanded upon in the Performance chapters of the "Stored
Procedures: Through The Call And Beyond" Red Book...

The memory usage is from concurrent stored procedures / UDF executions. So
the degree of concurrency can be important - and that is controlled by
NUMTCB. But you have to be careful when choosing a good NUMTCB value.as
you'll see (and as the Red Book explains).

WLM will actually use the memory usage of EXISTING server address spaces
for the work queue (combination of Service Class and Application
Environment) to decide whether to start additional server address spaces
for the queue. And therefore big server address spaces might inhibit their
siblings' being started. But CPU per server address space is likely to be a
bigger player. Conversely the smaller the address space's NUMTCB value the
greater the number of "start or delay starting" decisions. So that might
affect responsiveness.

There ARE options that can have an impact on the footprint per TCB. So
NUMTCB x footprint is what the address space uses. People have pointed them
out. Note: STAYRESIDENT is primarily going to affect the load module
memory, not the working storage. Keeping a JVM up seems likely to have
bigger impact - thought that's only relevant for java SPs / UDFs.

100MB and 200MB - the numbers mentioned so far are NOT particularly large
in the scheme of things. 4 years ago I worked with a customer that had 1GB
address spaces. Measuring the size is also difficult.

And, perhaps as an aside, I'd be also thinking about virtual storage - both
above and below the line. At this stage I doubt there are many cases where
SPs / UDFs use 64-bit virtual storage.

Hoping this sparks some discussion. :-)

By the way I found those chapters VERY difficult to write - as this is a
complex area (and actually we were still in a learning and thinking phase
about SP and UDF Performance).

Martin Packer
Performance Consultant
IBM United Kingdom Ltd
+44-20-8832-5167
+44-7802-245-584
[login to unmask email]


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Patrick Steurs

Re: WLM-adresspaces uses to much storage
(in response to Martin Packer)
Hi,



We use STAY RESIDENT for every own-written Stored Procedure. I think this has no impact as my other WLM-adresspaces don't have similar problems. The adresspace causing the problem is defined with NUMTCB = 25 and region-size O Mb. Normally it grows from a few Megabytes until 300 à 350 Mb. ( verified with the MXI-tool ). All my other WLM-adressspaces grow , but only from a few megabyte until maximum 20 MB. Do you know this problem-WLM-adresspace seems like not freeing storage ? Are is this WLM-adressspace is really consuming that much storage ? When i execute a "vary wlm,applenv=d2xxwlm1,refresh" command, storage is going down to his initial value for the new instance of the WLM-adresspace. ( For me, this seems to be normal )



greetings,



PAtrick Steurs

DBA at central bank of Belgium.



-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Martin Packer
Sent: maandag 8 januari 2007 11:24
To: [login to unmask email]
Subject: [DB2-L] WLM-adresspaces uses to much storage



First, let's be careful NOT to implicate WLM too much - not that anyone has

so far. :-)



I think it's worthwhile to tease out a few points about how this works.

These are points I expanded upon in the Performance chapters of the "Stored

Procedures: Through The Call And Beyond" Red Book...



The memory usage is from concurrent stored procedures / UDF executions. So

the degree of concurrency can be important - and that is controlled by

NUMTCB. But you have to be careful when choosing a good NUMTCB value.as

you'll see (and as the Red Book explains).



WLM will actually use the memory usage of EXISTING server address spaces

for the work queue (combination of Service Class and Application

Environment) to decide whether to start additional server address spaces

for the queue. And therefore big server address spaces might inhibit their

siblings' being started. But CPU per server address space is likely to be a

bigger player. Conversely the smaller the address space's NUMTCB value the

greater the number of "start or delay starting" decisions. So that might

affect responsiveness.



There ARE options that can have an impact on the footprint per TCB. So

NUMTCB x footprint is what the address space uses. People have pointed them

out. Note: STAYRESIDENT is primarily going to affect the load module

memory, not the working storage. Keeping a JVM up seems likely to have

bigger impact - thought that's only relevant for java SPs / UDFs.



100MB and 200MB - the numbers mentioned so far are NOT particularly large

in the scheme of things. 4 years ago I worked with a customer that had 1GB

address spaces. Measuring the size is also difficult.



And, perhaps as an aside, I'd be also thinking about virtual storage - both

above and below the line. At this stage I doubt there are many cases where

SPs / UDFs use 64-bit virtual storage.



Hoping this sparks some discussion. :-)



By the way I found those chapters VERY difficult to write - as this is a

complex area (and actually we were still in a learning and thinking phase

about SP and UDF Performance).



Martin Packer

Performance Consultant

IBM United Kingdom Ltd

+44-20-8832-5167

+44-7802-245-584

[login to unmask email]





---------------------------------------------------------------------------------

Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm




-----------------------------------------
Visit our website! http://www.nbb.be

"DISCLAIMER: The content of this e-mail message should not be
construed as binding on the part of the National Bank of Belgium
(NBB) unless otherwise and previously stated. The opinions
expressed in this message are solely those of the author and do not
necessarily reflect NBB viewpoints, particularly when the content
of this message, or part thereof, is private by nature or does not
fall within the professional scope of its author."


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm