Predicting and limiting ESQA usage

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.