Hello,

DB2 9.7 on a Linux server which has �TB of RAM:
In db2top's memory view, it states that the Lock Mgr is consuming 54G. 
This seems absurdly high to me. It seems that this value was chosen 
automatically:

$ db2 get db cfg |grep -i lock
 Max storage for lock list (4KB) (LOCKLIST) = AUTOMATIC(13692896)

Is there any conceivable reason why such a big lock list would ever be 
needed?

I would like to use as many automatically computed parameters as 
possible, except when it results in absurd results. Is there at way for 
me to influence the automatic calculation of the LOCKLIST value, without 
having to hard-code it completely?

It seems that DB2 needs to be restarted in order to change the value(?). 
So it's rather important to choose a good value from the start. In case I 
need to set the parameter to a fixed value: What would a pragmatic value 
be? (The documentation comes with a very long explanation which isn't 
really that useful, I think.)

-- 
Troels Arvin

El s=C3=A1bado, 13 de febrero de 2016, 18:23:15 (UTC+1), Troels Arvin  escr=
ibi=C3=B3:
> Hello,
>=20
> DB2 9.7 on a Linux server which has =E7=A2=BAB of RAM:
> In db2top's memory view, it states that the Lock Mgr is consuming 54G.=20
> This seems absurdly high to me. It seems that this value was chosen=20
> automatically:
>=20
> $ db2 get db cfg |grep -i lock
>  Max storage for lock list (4KB) (LOCKLIST) =3D AUTOMATIC(13692896)
>=20
> Is there any conceivable reason why such a big lock list would ever be=20
> needed?
>=20
> I would like to use as many automatically computed parameters as=20
> possible, except when it results in absurd results. Is there at way for=
=20
> me to influence the automatic calculation of the LOCKLIST value, without=
=20
> having to hard-code it completely?
>=20
> It seems that DB2 needs to be restarted in order to change the value(?).=
=20
> So it's rather important to choose a good value from the start. In case I=
=20
> need to set the parameter to a fixed value: What would a pragmatic value=
=20
> be? (The documentation comes with a very long explanation which isn't=20
> really that useful, I think.)
>=20
> --=20
> Troels Arvin

Have no idea why lock list is consuming such an absurd value.=20

We have used automatic STMM for some time to see how memory distribution ev=
olves in, say, one or two months. After that period we have seen the top va=
lues and assign them FIXED to the bufferpools or other memory consumers suc=
h as locklist (if you have enough memory).=20

I hope it helps