The following formulas and examples should help you to predict
and limit ESQA usage:
- Shared memory, shmat(), is typically used by server address spaces
to communicate with clients.
The
__IPC_MEGA option enables applications to use large quantities of
shared memory without system overhead. If you have applications taking
advantage of this __IPC_MEGA support, you do not need to be concerned
with the following calculations. The current usage can be calculated
by multiplying the number of pages by the number of (connections plus
3) by 32.
Example: If
a server that is not using 500000 bytes of shared memory and has 49
clients connected to it, the consumption of ESQA can be calculated
as:
500000 * (49 + 3) / 4096 * 32 = 203125
You
will find that 203125 bytes of ESQA, or approximately 200K, is needed.
The
49 plus 3 comes from 49 clients, 1 server, 1 anchor block, and 1 connection
to a kernel data space that is used to manage the storage. Some servers
use large amounts of shared memory that is shared by hundreds or thousands
of clients. This can require large amounts of ESQA (up to one gigabyte).
- mmap() is typically used by a single
process to map a file into virtual memory using the same sort of logic
used by DIV (Data In Virtual). Used in this manner, each page of the
file requires 3 RSM control blocks (anchor block, user page, and kernel
data space page). Each additional user sharing an mmap page of a
file will consume an additional control block.
The __MAP_MEGA option of mmap() enables applications
to map very large files without the system overhead in ESQA. If you
have applications using the __MAP_MEGA option, you do not need to
be concerned with the above calculations. If you are not using _MAP_MEGA
and issue mmap(), you can estimate the ESQA usage just as you would
for shared memory.
- fork() uses IARVSERV to capture
the parent's pages for the child's use. Each page captured represents
a requirement for three 32-byte RSM control blocks (parent, child,
and an anchor block per page). Since the child typically issues the
exec call soon after the fork, the ESQA used is short term. This
is countered by the probability that there are multiple forks going
on concurrently. Again, the amount of required ESQA can be calculated
by multiplying the size of the data area (in pages) to be copied by
the number of concurrent forks + 3 by 32.
Example: Assuming
the Language Environment® runtime
library is not in LPA, a typical shell will have 5 MB of private to
copy on fork. If there are, on average, 10 forks running concurrently,
then the following ESQA is needed:
5MB * 256 pages/MB * (10 forks + 3) * 32 bytes/page
You
will find that 532 KB of ESQA is needed.
If the runtime library
does reside in LPA and each process has an average of 1 MB of private
to copy, then:
1MB * 256 pages/MB * (10 forks + 3) * 32 bytes/page
You
will find that 106 KB of ESQA is needed.
- ptrace() uses captured storage to allow the debugger to map the
program being debugged into private storage that the debugger can
refer to frequently. The amount of ESQA that is required can be calculated
as the number of pages of storage required times the number of concurrent
debug sessions +2 by 32.
Example: To calculate the amount
of storage that will be needed if a programmer is debugging a 1-MB
program and a 200 KB automatic data stack that are both captured:
1.2MB * 256 pages/MB * (1 debug session + 2) * 32 bytes/page
The
answer is 29 KB of ESQA.
To predict the amount of ESQA required to support applications,
you need to understand which applications use shmat() and mmap().
You need to approximate the amount of fork() and dbx debugger activity
as well. Then plug your numbers into the equations for each function
to determine the amount of ESQA needed.
In BPXPRMxx, specify the maximum number of shared storage pages
that can be used on the MAXSHAREPAGES statement. By limiting the amount
of shared storage pages used, MAXSHAREPAGES lets an installation control
the amount of ESQA storage that is consumed by users.
This limit applies to the mmap(), shmat(), ptrace(), and fork()
callable services.
The fork() and ptrace() callable services use shared storage pages
to improve performance. Because use of shared storage pages is not
critical to completion of these functions, when the amount of shared
storage pages in use reaches about 60% of the specified limit, these
functions no longer use shared storage pages. The mmap() service continues
to use the shared storage pages until the total resource consumption
reaches about 80% of the limit. The shmat() callable service continues
to use shared storage pages until the total resource consumption reaches
the specified limit.
The mmap() and shmat() callable services return an out-of-memory
condition when they can no longer obtain shared storage without exceeding
their respective shared storage limits.
There is also a FORKCOPY parameter in BPXPRMxx that prevents fork
from using the IARVSERV function.