Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: OCI memory usage
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 0x00040000Received on Fri Oct 29 1999 - 08:21:38 CDT