DB2MEMDISCLAIM - clarification

[m***@yahoo.com]

Hi all ,
We have a c++ server running on Aix 5.2 which uses db2 v8.1.1.8 with Fixpack
We are seeing a intermittent jumps in the memory using the "ps gv" command. The memory delta was in the range of 4k, 8k and 12k . Most of the Memory leak tools like Memory validator ( code on windows ), purify etc detected no leaks in the appilcation.

Then we started looking at the third party libraries used in the system for AIX . The DB2MEMDISCLAIM seemed to be an interesting candidate. we tried setting the DB2MEMDISCLAIM to yes and DB2MEMMAXFREE to null. The intermittent jumps have stopped for now after the change .

What i understand is that the DB2MEMDISCLAIM settings would control the db2agents behavior and not of the appication which is connecting to the db2 as such. Can somebody please explain me if i am missing anything here.

Please let me know if any moreinformation is required.

[l***@ca.ibm.com]

Hello,

DB2MEMDISCLAIM and DB2MEMMAXFREE affect both the DB2 application side, and the server (agent) side. By default, 8MB of private memory will be cached (on both the app and server side) before DB2 releases memory back to the OS. On AIX by default, that memory is disclaimed as it is released, to ensure that freed memory does not occupy physical RAM or paging space (so, you shouldn't have to change the default DB2MEMDISCLAIM setting).

Did you change DB2MEMMAXFREE to null ('db2set DB2MEMMAXFREE -null'), or 0 ('db2set DB2MEMMAXFREE=0')? Setting it to null means that we continue to use the default 8MB threshold. Setting it to 0 means that we immediately release any free memory back to the OS. This can have a negative effect on performance of the DB2 server in particular, and can potentially cause memory fragmentation. If setting DB2MEMMAXFREE to 0 fixes the problem, then it wasn't really a leak - DB2 was just caching memory in it's memory manager for improved performance.

If you are happy with your solution, and do not observe any noticeable performance impact (the server side won't see this change until after a db2stop/db2start), then this change should be fine. DB2MEMMAXFREE is typically used though for systems that have a large number of agents, to reduce the amount of physical memory held by idle agents - a common setting in those environments is 2MB (2097152).

Cheers,
Liam.

[m***@yahoo.com]

Thanks for your reply Liam,
that sure did help us in understanding the effect of these settings on the application, Can you please point us to some resources which describes the same.

as the settings are concerned , we had set the DB2MEMMAXFREE to null which again as you said sets it to 8mb. We will try the same experiment by setting the DB2MEMMAXFREE=0 and check if it changes anything.

You had mentioned "the server side won't see this change until after a db2stop/db2start". So does that mean if i change the settings without db2stop/db2start only the application is affected by this change and not the server.


Thanks for you help

~tf

[m***@yahoo.com]

Thanks for your reply Liam,
that sure did help us in understanding the effect of these settings on the application, Can you please point us to some resources which describes the same.

as the settings are concerned , we had set the DB2MEMMAXFREE to null which again as you said sets it to 8mb. We will try the same experiment by setting the DB2MEMMAXFREE=0 and check if it changes anything.

You had mentioned "the server side won't see this change until after a db2stop/db2start". So does that mean if i change the settings without db2stop/db2start only the application is affected by this change and not the server.


Thanks for you help

~tf

[l***@ca.ibm.com]

Hi tf,

The only documentation I know of is in the DB2 v9 books when discussing those two registry variables.

Your other statement is correct - the server will not be affected by changes in those registry variables until it is restarted. New applications will pick up those changes though (currently running applications won't see them).

Cheers,
Liam.