OpenEdge 10.1B introduced three major changes with respect to how it creates and uses database shared memory segments:1. The
-shmsegsize database startup parameter allows control over the
"maximum" segment size that will be created. The actual segment sizes that are created may be smaller than this due to a variety of factors such as:
- The amount of shared memory needed may be less than the maximum shared memory segment size,
- The Operating System's maximum segment size may be smaller,
- The value of SHMMAX, and other kernel tunable parameters may have lower limits.
2. The OpenEdge 10.1B
default shared segment size is different (and larger) than the previous fixed maximum of
128 megabytes for 32-bit systems. If the Operating System allows, fewer but larger segments will be created by default. For some Operating System, this facilitates the use of slightly larger database buffer pools with 32-bit versions of OpenEdge.
3. 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. Some data structures which are quite numerous, such as database buffer pool headers and lock table entries, will consume noticeably more memory than before. For example:
- The Lock Table (-L) has increased from 16-18 bytes each in 10.1A to 64 bytes each in 10.1B.
- Index cursors have increased for 24 to 34 bytes each.
While these changes have definite advantages, they are not without some drawbacks. Thus it is possible that customers on 32-bit systems who upgrade from earlier releases may see errors related to shared memory because the segments cannot be allocated within the available address space.
Consequences that will arise from OpenEdge 10.1B Shared Memory Changes:1.
The database server will not start because all the data structures won't fit as they did before. Lowering the value of -B by 10 percent or so may overcome this issue when the value of -B is large and already close to the maximum amount of shared memory the system allows. On UNIX systems, adjusting the shared memory segment size to match kernel setting for SHMSEG.
2. The database server starts but
clients cannot connect in self-serving mode. This may be caused by lack of sufficient
contiguous free address space in combination with the larger default segment size used by the database broker. Lowering the value of
-shmsegsize may overcome this issue because when the address space has several smaller holes, the Operating System may be able to find space to locate the segments in them. This is more likely to happen on Windows, where the system has mapped .dll's in a manner such that there are no large chunks of free address space. The problem is similar to that of filling a box with variable size blocks of wood. Small blocks are easier to fit than larger ones.
3. There may be a
conflict between large shared 4GL procedure libraries (which are mapped in a single contiguous memory segment)
and large shared memory segments created by the server. Lowering the value of
-shmsegsize may help.
4. A client that connects to
multiple databases in self-serving mode may no longer be able to attach to shared memory. This can happen due to larger segments. See 1) above.
In no case can there be 4 GB of shared memory on 32 bit systems because the entire address space is 4 GB and all of it cannot be used for shared memory. Most 32-bit Progress versions are limited to approximately 2 GB of shared memory. On some Operating Systems the limit is a bit smaller and on some a bit larger.
