On 11/24/2004 02:45:01 PM, Jeffrey Beckstrom wrote: > Our initial thought was we could combine our current two-tier apps > servers for the Oracle Apps by putting all of the test instances on > one > set of two-node linux boxes. > =3D20 > However, if we are stuck to a total of 4g, this will not help since =20 > in > w2k, we are already using 1.3+ G per instance. Or would each oracle > process on linux have its own 4g limit meaning we could have several > large instances running. Ah, that is the problem! Winduhs architecture is based on threads. =20 Threads, as opposed to processes, share the same address space. Thing =20 is done like this: any operating system has a structure that defines a =20 process. The structure normally contains user credentials, address of =20 the segment table for the user mode of operation, the segment table for =20 the kernel mode of operation and the set of registers. Each segment has =20 a page table and is mapped to a virtual address in the user's kernel =20 address space. Kernel address space is global within itself. That means =20 that the each address in kernel space points to the same location in =20 different processes. Each process has its own segments. In pre-ELF =20 unixes, they used to be called stack, text, data and BSS. Now it is not =20 so, each shared library mapped into your process is a segment and has =20 its own page table. Kernel of each OS has a structure called process table which contains a =20 list of the structure of the above type. Each process has its own =20 process structure pointing to its own set of segment and page tables. Add stem cell research and modern biology into the brew and allow =20 process entries to spawn "children", which are not fully adult =20 processes, but minor processes, sharing the same page tables. That =20 means that the threads are sharing the same address space. The 4GB limit applies to ALL of the threads because they all share the =20 same page tables (address space). Oracle on "processes" Winduhs (SMON, PMON,LGWR,DBWR and ARCH) are all =20 threads, which means that the code for each them must be subtracted =20 from the common address space, decreasing therefore the space available =20 for SGA and severely reducing your potential for a good BCHR. That was =20 done because Winduhs doesn't support POSIX compliant IPC services, so =20 the only way for the two processes to share an area of memory is to =20 share the address space. Programming threads is quick and easy because =20 threads synchronization is much simpler then using semaphores or a =20 post-wait device. Unix processes are created using "fork" system service which clones a =20 process from its parent and creates a copy of its page tables marking =20 them as copy-on-write in the process. That is, I believe, explained in detail by Bach in "Magic Garden Explained" and "Toccata & Fugue". VMS has had a system service called $CREPRC (or something like that) which =20 would create it from the scratch, without cloning. Copying symbol =20 tables required quite a bit of I/O The point is that oracle on non-winduhs OS-es is process based, not =20 thread based. Each process is its own animal and doesn't trespass onto =20 address spaces of the others. Code for LGWR operates in completely =20 separate address space from the code for SMON and both have nothing in =20 common with the code for the DBWR. The only space they share is called Shared Global Area, otherwise known as SGA. POSIX shared memory or System V shared memory, as it is sometimes =20 called, is, essentially, a memory mapped device which creates a special =20 type of page tables and calls like shmat, shmget or shmop are =20 implemented as calls to a driver. Implementation of the system services as "change mode to kernel" traps with special arguments is beyond the =20 level of this message. Bottom line is that despite both Linux and Win2k being 32 bit systems, =20 the usable memory area is much larger on the Linux system. To make the long story short, Windows sucks. Have a pleasant =20 thanksgiving. --=20 Mladen Gogala Oracle DBA -- //www.freelists.org/webpage/oracle-l