Kbase P138375: 10.1C Shared memory leak on database connections
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
07/05/2009 |
|
Status: Verified
SYMPTOM(s):
10.1C Shared memory leak on database connections
Errors 14394 start appearing in the database lg file after many connect disconnects
Out of free shared memory. (14394)
Database forces Abnormal shutdown with error 6495
Out of free shared memory. Use -Mxs to increase. (6495)
Each connect and disconnect results in 168 byte of freeshared memory not being released
Monitoring shared-memory through promon shows ~ 560 KB memory lost over 24 hour period
Database has a high connect/disconnect rate
There are no Lock table overflows associated with the shared-memory depletion
Lock table overflow, increase -L on server (915)
FACT(s) (Environment):
OpenEdge 10.1C
OpenEdge 10.2A
All Supported Platforms
All Supported Operating Systems
CAUSE:
Bug# OE00177639
CAUSE:
For each Client/Server connection to the database, 168 bytes are allocated from the shared-memory pool. In OpenEdge 10.1C this was deliberately left behind for re-use (on the next connection) instead of having to deallocate and reallocate for every connection. Unfortunately, the database manager was over-writing the pointer to the 'left-behind' allocation from the client server connection causing the 168 bytes to be reallocated every time a new client server connection is made. This leak eventually leads to exhausting the total allocated shared-memory, where the rate of attrition is 168 bytes per Client/server connect/disconnect (ie network connections). Once the shared memory is exhausted, any connection will fail allocating shared-memory (ie including self-service connections).
FIX:
Upgrade to 10.1C03, 10.2A01 where the memory allocated for client/server connections still remains, but the memory will be reused anytime that connection is reused for other client/server connections before allocating more memory.
If not possible to upgrade at this time use the following workaround:
1. Ensure that the current settings for shared-memory are sufficient for 'normal' operations. Specifically: -B, -Mxs, -shmsegsize and -maxAreas are all set to an environment-appropriate value rather than the defaults.
2. Monitor Shared-Memory either through promon > R&D > 1. Status Displays > 14. Shared Memory Segments
or the following ABL code:
FOR EACH _Segments:
DISPLAY _Segment-ByteFree _Segment-BytesUsed.
END.
To avoid an Emergency shutdown of the database when "free memory" starts exhausting:
Example:
Seg Id---------Size---------used---------free
1 20971537 733454336 730158792 3295544
.. time ..
1 20971537 733454336 733355648 98688 (/168 = circa 580 connects remaining)
Increase -Mxs online with:
$ proutil dbname -C increaseto -Mxs <value in KB>
NOTE:
0. The user running this cmd, must have the appropriate permissions to execute this utility. Please refer "OpenEdge Management: Database Administration - proutil increaseto qualifier"
1. All current promon connections must be stopped prior to running the 'proutil -C increaseto'
2. If existing connections have not yet connected to the shared memory or an additional shared-memory segment needs to be allocated to satisfy the 'proutil -C increaseto' argument, a message will appear listing these connections and prompt "yes
o" to wait.
Either: these connected users need to 'do something' to re-address the shared-memory segments or they need to be disconnected before the additional shared memory can be allocated.
Eventually the database /will/ need to be shutdown to release the memory associated with the leak (circa 168bytes per connect/disconnect).