Kbase P81385: Real limits for Buffer Pool with 9.1 and later, for 32-bit architectures
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/25/2004 |
|
Status: Unverified
GOAL:
Real limits for Buffer Pool with 9.1 and later, for 32-bit architectures
FIX:
With 9.1 and later, on 32-bit architectures, the maximum number of buffers allowed is 125,000,000. However, this is only the DESIGN LIMIT. There are other factors that are likely to make the practical limit be much lower.
Some of the limits are related to the Progress database design, some are related to the policies the underlying operating system uses to manage memory, and some are related to the processor virtual memory design.
The Progress design limits (for 32-BIT versions, 9.1 and later) are:
1. Maximum allowed value for -B: 125,000,000 buffers.
2. Maximum usable shared memory segment size: 134,217,728 bytes.
3. Maximum number of shared memory segments: 21 segments.
Note that 128 megabytes times 21 is about 2.7 GB.
4. You don't get to use all the shared memory for database buffers. There are other things that must also fit. The buffer pool is typically the largest contributor but the list includes:
* database buffers (-B times database block size)
* database buffer headers (-B times 120)
* bi buffers (-bibufs times 16k, regardless of bi block size)
* ai buffers (-aibufs times 16k, regardless of ai block size)
* lock table (-L times 36)
* connection table (((-n + 3) times 900) + (-Mn times 900))
* transaction table (size of connection table * 50)
Those numbers are approximate.
In addition to these limits, the operating system has limits too. In practice, you are unlikely to be able to get 2.7 GB of shared memory on most systems.
For 32-BIT systems, the total address space of any process is limited to 4 gigabytes. Of this, the operating system will normally not give all of it to an application program - it reserves some of it for itself. There may be a limit to the segment size or the number of segments allowed. A few examples of different OS limitations:
* Windows 2000: limits the application to 2 GB (3 GB under special circumstances).
* AIX: a process can attach no more than 11 shared segments under normal circumstances.
* HP-UX: total system-wide shared memory is limited to 1.75 gigabytes unless you use the "memory windows" feature.
They all make different tradeoffs.
Out of whatever fraction of the address space you have to work with, all the program's code and data must be fit into it. This includes:
* The code for the program itself (the "text segment" on Unix)
* Code in shared libraries or dynamic link libraries ("dll's") the program uses, directly, or indirectly
* The program stack
* Thread stacks
* Constant or static data
* Global variables
* The "heap", a pool of private memory from which space for various temporary data structures, like Progress widgets, r-code buffers, record buffers, etc. is taken from
* Shared memory segments
* File buffers for open streams
* Memory mapped files
* etc, etc, etc,
The sizes of all of these vary depending on what your 4GL application uses.
For example, if you have a 1 gigabyte 4GL shared procedure library (a /very/ large library), that will consume a substantial portion of your address space, leaving less room for shared memory.
You may be able to start a server with some given value for -B, but the clients may not be able to attach that many segments.
If your application connects to more than one database as self-serving, then the shared memory segments from all the databases must be attached to the client process. If you max out -B for all of them, this will probably not be possible.