OpenEdge 10.1B has three major changes with respect to how the Database Manager creates and uses database shared memory segments:
- The default shared segment size is different (and larger) than the previous fixed maximum of 128 megabytes for 32-bit systems.
- The database's data structures that are placed into shared memory are larger than they were in prior releases. In particular, shared pointers are now 64 bit and they were 32 bit in prior releases.
- The -shmsegsize database startup parameter was added as a database startup parameter which allows control over the "maximum" segment size that will be created.
-shmsegsize: Minimum value
- 128 MB for 32-bit OpenEdge
- 1024 MB for 64-bit OpenEdge
-shmsegsize: values (MB)
- 32-bit OpenEdge: 128, 256, 512, 1024, 2048
- 64-bit OpenEdge: 1024, 2048, 4096, 8192, 16384, 32768
Pre-OpenEdge 10.1B behaviour can be forced by adding "-shmsegsize 128
" for OpenEdge 32-bit or "-shmsegsize 1g
" or "-shmsegsize 1024"
for OpenEdge 64-bit, to the database startup parameters.
Since OpenEdge 10.1B when the database startup parameter "-shmsegsize
" is not specified, the database manager attempts to determine the best single shared memory segment size
to use based on the shared memory the database server requests and rounds up to the next available value.
Once the database has started, the number of shared memory segments and their size can be viewed. Refer to Article:
If the code determines that a 2GB segment should be used, but the machine is configured for a maximum segment size of 1GB, a 1GB segment will be created and then 1 or more segments at the maximum size until the Shared memory requirements are met, where the last segment will be the smallest.
Increasing the size of the shared memory segments decreases the number of segments allocated, in turn decreasing the system resources needed to manage the segments. In general, use a shared memory segment size (-shmsegsize
) to specify the size of the largest shared memory segment the server can allocate. However on 32-bit OpenEdge care should be exercised when more than 1GB of shared memory is used.
A potential problem with allowing the Database Manager to allocate the shared memory segment size is that the database may fail to start or will start and clients may fail to connect self-service when the calculated shared memory size:
- Is larger than the amount of contiguous shared memory that can be attached on Windows or
- Conflicts with the shared-memory kernel parameters (SHMMAX, SHMSEG) on Unix
- For further information refer to Articles:
For this reason, it is recommended to explicitly specify the shared memory segment size to use with the -shmsegsize
database startup parameter as opposed to relying on the default calculation. As a rough guide, add the sum of -B and -B2 and multiply by the database blocksize. Then use a valid shared memory segment size lower than the size that would be used if rounded up.
(-B + -B2 ) x blocksize = 250000 x 4 = 1 GB
- -shmsegsize = 2048 default, 1 shared memory segment. Due to other database's data structures (-L, -maxareas, -Mxs etc) pushing the shared memory requirement over 1GB, the next shared memory segment size used is 2g, so one shared memory segment is used with quite a lot of space free.
- -shmsegsize = 1024, 3 shared memory segments will be used to satisfy the shared memory requirement with the last the last segment having the same amount of space free as above.
- -shmsegsize = 512, 3 shared memory segments will be used to satisfy the shared memory requirement with the last the last segment having appreciable space free.
- -shmsegsize = 256, 5 shared memory segments will be used to satisfy the shared memory requirement with the last segment having the least space free.