When the database manager starts up, it creates the shared memory area during initialization. To create the shared memory, it must know how much space it needs to allocate. This size is computed by analyzing the values of various startup parameters and the sizes and number of the various data structures that will populate shared memory.
This Excess Shared Memory Size (-Mxs) feature is provided for cases where the calculated shared memory value turns out to be too small or to steal one extra structure when the configured database startup parameter is under scoped. The -Mxs parameter tells the database manager to allocate more than what it has calculated will be needed. The current value for -Mxs is reported in the database.lg file at startup.
You may see the need to increase -Mxs indicated by a System Error, which reads:
(14394) Out of free shared memory.
(6495) Out of free shared memory. Use -Mxs to increase.
(1185) Out of free shared memory. Use -Mxs to increase.
Specify the Shared-memory Overflow (-Mxs) startup parameter when starting the database to replace the default value of the shared-memory overflow area. The overflow area will then be appended to the existing shared-memory area; it does not increase the shared-memory area but is dynamically allocated as needed. Depending on the operating system, the database engine rounds the shared-memory area size to the next 4K or 8K boundary.
The multi-user calculation of the default value for -Mxs parameter for 32-bit systems is:
[16384+(n*300)] / 1024 = -Mxs (KB),
where n is the number of users.
As an example, if the database is started with -n 100 the default -Mxs value will be 45 KB.
Prior to version 12 the multi-user calculation of the default value for -Mxs parameter for 64-bit systems is:
[16384+(n*400)] / 1024 = -Mxs (KB),
where n is the number of users.
As an example, if the database is started with -n 100 the default -Mxs value will be 55 KB.
Beginning in OpenEdge version 12 there is a new default value for the -Mxs:
[32768+(n*480)] / 1024 = -Mxs (KB),
where n is the number of users.
As an example, if the database is started with -n 100 the default -Mxs value will be 63 KB.
Why the calculated -Mxs value might be undersized:
1. The computation is not exact. For example, as shared memory is allocated we do not know how many segments will be required by the time it has completed. There is some overhead in the beginning of each segment to keep track of the space. The more segments, the more overhead.
2. There are variable size structures (index key values in index cursors) kept in shared memory. The size varies according to what the application does, how indexes are defined, and what the key values are. We estimate how much memory will be needed for these. If the estimate turns out to be wrong, we need a way to override it.
3. Bugs. Progress may have added a data structure not included it in the computation or done the new computation incorrectly. For example, mandatory fields, please refer to Article Save Cache option causes 6495 error
When is -Mxs used:
There are many shared memory structures that 'steal' from -Mxs. Among these are:
- Prior to 9.1E03, OpenEdge 10.1A, 10.0B04, when the number of database areas exceed 1024, the initial shared memory reserved for database areas is not enough and the shared memory required for the area definitions must be allocated from the extra shared memory
- When AI is enabled, the memory that was once considered "extra" is utilized by the AI subsystem.
- Mandatory fields take memory from -Mxs but are not included in the default -Mxs calculation. Refer to Article Save Cache option causes 6495 error.
- When configured database startup parameter is under scoped one extra structure is allocated from Excess Shared Memory. For example, (notoriously) Lock Table Overflow (915) can cause a 6495:
When a Lock Table overflow 915 error occurs, the database engine tries to supply more slots from "-Mxs to -L" in order to try to complete request since the -L table is exhausted. Since OpenEdge 10.1B and later each Lock Table Entry size is 72 bytes for both 64 and 32 bit. Each time there is a 915, 72 bytes are taken from -Mxs for one extra Lock Table entry. When there are many 915 errors, the -Mxs excess memory is eventually exhausted and no more -L entries can be added. As there are no more Lock Table entries, this is a fatal error for a database engine because the database engine cannot then no longer properly handle the rollback of the transaction without enough free shared memory available.
Hitting error (6495) after (915) is expected, it is not a bug. Each time there is a Lock Table overflow, Progress needs to add one additional Lock Table entry (-L). The memory for the extra entry comes from whatever free shared memory happens to be available (-Mxs). The Lock Table size gradually grows until there is no more free shared memory left when error 6495 is posted. Increasing -Mxs to allow the Lock Table size to extend can be considered in addition to increasing the initial Lock Table size, but excess shared memory should not be relied on for under scoped database shared memory structures as it is used for overflow in other shared memory structures as well.
