Kbase 17447: PROLIB Swap (-pls) and its relation to Maximum Memory(-mmax)
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
PROLIB Swap (-pls) and its relation to Maximum Memory(-mmax)
In a client-server environment,the -mmax Maximum Memory parameter can
be helpful in predefining the execution buffer size for the client.
The execution buffer is the amount of memory allocated for rcode
segments in kilobytes.The single and multiuser default is 512,and the
maximum value is 65,534 (in kilobytes). Using this parameter is
especially helpful when using large or deeply nested procedures as it
reduces disk i/o required to swap these rcode segments to the sort
file.
The confusing part of using this parameter is that it is documented as
being able to "dynamically allocate" memory as needed for larger,more
nested procedures.This is a true statement,however the cost of this
dynamic memory allocation can be expensive memory and performance
wise.
When the maximum value for -mmax is reached for the client,meaning the
rcode being used by the client exceeds the size of the preset
execution buffer defined by -mmax,we swap nonactive rcode segments to
the sort file to make room for the new procedures we need to use. The
i/o required for this sorting is expensive performance wise,and if
there is not enough space in the srt file to swap these rcode segments
,we will dynamically allocate more memory to the client to increase
the size of the execution buffer to accommodate the needed rcode.This
is typically an unforeseen memory expense as users typically don't
adjust -mmax based on the rcode needs of the client.
The (-y) and (-yd) statistics parameters can be helpful in monitoring
segment allocation information.
When using Procedure Libraries,it can also be helpful to use the
(-pls) startup parameter on the client. This is the PROLIB Swap
parameter.Progress typically reads rcode files directly from the
libraries instead of swapping the files into temporary sort files.
This is fine for local clients,however these direct reads are
expensive performance wise over a network.Therefore we can opt to
store these rcode files locally in temporary sort files to eliminate
the performance hit of direct reads. This parameter is only effective
over a network.
These client memory paramters are useful if used correctly,but can
cause unnecessary and unanticipated memory consumption by the client
if not set properly.If the rcode is unusually large or nested,then
make the necessary adjustments to -mmax before hand to prevent the
unnecessary memory consumption. Also remember that direct reads from
procedure libraries over a network can be expensive as well.
REFERENCES TO WRITTEN DOCUMENTATION:
System Administration Reference 4-75 and 4-90.
12/1/97 SDA
Progress Software Technical Support Note # 17447