Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: OCI memory usage

Re: OCI memory usage

From: seb <sebflsh_at_hotmail.com>
Date: Fri, 29 Oct 1999 14:21:38 +0100
Message-ID: <941199615.358387@dedale.pandemonium.fr>


Here is the answer from Oracle :

Seb.

...
In 8.1.6+, the first process started will use 8MB of RAM for code and memory allocations, and each additional process will
only added dynamic memory allocations to the memory usage... no longer will there be additional allocations based on code size.

Here is the techical detail on this issue:

On NT, when you build a DLL, you can tell the linker the base
address at which you want NT to load that DLL. By default, DLLs will try to load at address 0x10000000, unless you tell the linker otherwise. When a process starts up, NT starts loading DLLs into that process' address space at the base addresses specified in the DLL. When it comes to a DLL that can't be loaded at it's base address (because there's already
something at that address), then NT needs to relocate the DLL
and fix up any addresses inside the DLL's code. When it does these fix ups, NT allocates memory for an entirely
new copy of the DLLs code (since it's writing into the code segment to do the fixups).
This is the cause of the high per process memory requirements
you are seeing....lots of DLLs gettng relocated and fixed up.

Currently, we at Oracle don't specify base addresses for our DLLs, and they therefore all collide since they want to load at 0x10000000. They then all get relocated, and each process
gets their own private copy of the DLLs code, causing high memory usage in multi-process situations.

Starting in v8.1.6, when we link DLLs we will specify the base
addresses that do not collide, which will avoid the relocation
issue, which will allow multiple processes to share the same copy of the DLL code and only take the hit for the code size once for the entire system. So, running 5 or 50 or 500 processes
will only result in one copy of each DLL being loaded in memory.

Prior to 8.1.6, customers can do their own re-basing of the DLLs
if there's an urgent need by using a utility from Microsoft's
Visual C++ compiler distribution called 'editbin'. Using the 'editbin /rebase' option allows you to rebase a DLL
that you have on your system such that it doesn't collide with
other DLLs.

Binary patch for 8.1.5 DLLs :

DLL address size


oci              0x64000000 0x00020000
oraansi          0x64020000 0x00010000
oraclient8       0x64030000 0x000b0000
oraclm32         0x640e0000 0x00020000
oracommon8       0x64100000 0x00060000
oracore8         0x64160000 0x00080000
oracore8.sav     0x641e0000 0x00080000
oradbicx8        0x64260000 0x00010000
orageneric8      0x64270000 0x00110000
oraldapclnt8     0x64380000 0x00020000
oramts           0x643a0000 0x00020000
oramtsf          0x643c0000 0x00020000
oramtsus         0x643e0000 0x00020000
oran8            0x64400000 0x00100000
oranbeq8         0x64500000 0x00010000
orancrypt8       0x64510000 0x00010000
oranhost8        0x64520000 0x00010000
oranipc8         0x64530000 0x00010000
oranjni8         0x64540000 0x00010000
oranl8           0x64550000 0x00030000
oranldap8        0x64580000 0x00010000
oranldapj8       0x64590000 0x00010000
oranls8          0x645a0000 0x00050000
oranlu628        0x645f0000 0x00010000
orannds8         0x64600000 0x00010000
orannmp8         0x64610000 0x00010000
orannms8         0x64620000 0x00010000
orannss8         0x64630000 0x00010000
orannts8         0x64640000 0x00010000
oranoname8       0x64650000 0x00010000
oranoncj8        0x64660000 0x00010000
oranoss8         0x64670000 0x00010000
oranro8          0x64680000 0x00040000
oransslb8        0x646c0000 0x00010000
orantcp8         0x646d0000 0x00010000
orantcps8        0x646e0000 0x00010000
orantns8         0x646f0000 0x00010000
oraplc8          0x64700000 0x00010000
oraplp8          0x64710000 0x000c0000
orapls8          0x647d0000 0x00210000
oraslax8         0x649e0000 0x00010000
orasql8          0x649f0000 0x00070000
oratrace8        0x64a60000 0x00040000




Received on Fri Oct 29 1999 - 08:21:38 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US