This content has been marked as final. Show 8 replies
Try using the OS command "ipcs -m" to figure out the addresses at which shared-memory segments on this box start from and extend to. This should allow you to determine which shared memory segment is occupying the address at which TT wants to place its PLSQL memory segment. ipcs -ma will give you extra details such as PIDs, and this might allow you to identify who is using the already existing memory segment.
You need to identify a 'free' region within the process address space where the segment can be attached. The address space map for a process can be displayed using an O/S tool such as 'pmap'. In your case as this is Weblogic you need to use pmap on the JVM process ('java'). Find a suitable 'gap' of a size at least large enough for the size of the PLSQL shared memory segment and set PLSQL_MEMORY_ADDRESS to the start of that gap.
... used the pmap on the JDK process used by weblogic server.
*4304 4269 0 Sep09 ? 00:00:42 /usr/local/bea103/jdk160_11/bin/java -client -Xms256m -Xmx512m -XX:CompileThreshold=8000 -XX:PermSize=48m -XX:MaxPermSize=128m-D*
then pmap on 4304
those are the last rows printed:
*00000000f7fd9000 4 - - - r-xs- config-launch.jar*
*00000000f7fda000 4 - - - r-x-- locale-archive*
*00000000f7fdb000 24 - - - r-x-- locale-archive*
*00000000f7fe1000 32 - - - rwxs- 4304*
*00000000f7fe9000 36 - - - r-x-- libnss_files-2.3.4.so*
*00000000f7ff2000 4 - - - r-x-- libnss_files-2.3.4.so*
*00000000f7ff3000 4 - - - rwx-- libnss_files-2.3.4.so*
*00000000f7ff4000 24 - - - r-x-- libhpi.so*
*00000000f7ffa000 4 - - - rwx-- libhpi.so*
+*00000000f7ffb000 4 - - - rwx-- [ anon ]*+
+*00000000f7ffc000 4 - - - r-x-- [ anon ]*+
+*00000000f7ffd000 4 - - - rwx-- [ anon ]*+
+*00000000ffff5000 36 - - - rwx-- [ stack ]*+
+*00000000ffffe000 4 - - - [ anon ]*+
i don't know much about -_- memory addresses..can you tell me how i decide a range?
tried 00000000fffff000 but got _703: Subdaemon connect to data store failed with error TT9999_.
Thanks in advance for any help and patience :).
Edited by: Tori on Sep 10, 2009 9:03 AM
Edited by: Tori on Sep 10, 2009 9:03 AM
Every process is assigned a virtual address space by the O/S. For 32-bit O/S this space is typically 4 GB in size and for a 64-bit O/S the space is typically 17,179,869,184 GB in size (pretty large!). Of course, this is virtual space and most of it does not corrspond to real mmory and indeed, especially on 64-bit, most of the address space is 'empty' (i.e. not mapped to anything at all). When a process uses memory for something, some part of the address range becomes mapped to actual virtual memory of which some fraction is, at any one time, mapped to real, physical memory.
Addresses within the address space are a contiguous ascending sequence starting at 0 and incrwasing to the maximum size of the address space. Addresses are usually expressed as 32 or 64 bit hexadecimal values. So, for a 32-bit process the address range is 0x00000000 through to 0xffffffff while for a 64-bit process it is 0x0000000000000000 through to 0xffffffffffffffff. In general, the O/S will 'reserve' some parts of the address range for things like shared library/DLL loading and so on but this varies from O/S to O/S.
When a process attaches to a shared memory segment the segment has to be mapped into the process' address space. It can onloy be mapped into an area of the address space that is currently unused (i.e. it cannot 'overlap' anything already mapped in the address space. The key things are the start address at which the segment will be mapped and the size of the segment. By default, the TimesTen PLSQL shared memory segment is 32 MB in size (unless you have changed this by specifying a different value for PLSQL_MEMORY_SIZE). That is 0x00200000 in hex. So, we need to find an 'empty' space in the process address map that something of this size can fit into...
Tyhe 'pmap' command displays an address space map of a process. Each line represents a 'used' address range and is expressed in terms of the start address (in hex) the size of the area (usually in KB but see 'man pmap' for specifics) the memory protection attributes for that range and some info on what is mapped at that location (shared librray, data, stack etc.). What you need to do is to look at the (whole) output of pmap and find an address range that is at least 32 MB in size that is not usedfor anything. Note that pmap does not display unused ranges so you need to infer the presence of an unused area by looking at what is actually used. For example, consider the following pmap for the Linux shell, bash on 64-bit Linux:
[cdjenkin@reliant1 ~]$ pmap 2868
0000000000400000 712K r-x-- /bin/bash
00000000006b2000 40K rw--- /bin/bash
00000000006bc000 20K rw--- [ anon ]
00000000008bb000 32K rw--- /bin/bash
000000000b846000 380K rw--- [ anon ]
0000003329e00000 112K r-x-- /lib64/ld-2.5.so
000000332a01b000 4K r---- /lib64/ld-2.5.so
000000332a01c000 4K rw--- /lib64/ld-2.5.so
000000332a200000 1328K r-x-- /lib64/libc-2.5.so
000000332a34c000 2048K ----- /lib64/libc-2.5.so
000000332a54c000 16K r---- /lib64/libc-2.5.so
000000332a550000 4K rw--- /lib64/libc-2.5.so
000000332a551000 20K rw--- [ anon ]
000000332aa00000 8K r-x-- /lib64/libdl-2.5.so
000000332aa02000 2048K ----- /lib64/libdl-2.5.so
000000332ac02000 4K r---- /lib64/libdl-2.5.so
000000332ac03000 4K rw--- /lib64/libdl-2.5.so
000000332ea00000 12K r-x-- /lib64/libtermcap.so.2.0.8
000000332ea03000 2044K ----- /lib64/libtermcap.so.2.0.8
000000332ec02000 4K rw--- /lib64/libtermcap.so.2.0.8
00002b3fe488c000 4K rw--- [ anon ]
00002b3fe48ab000 12K rw--- [ anon ]
00002b3fe48ae000 40K r-x-- /lib64/libnss_files-2.5.so
00002b3fe48b8000 2044K ----- /lib64/libnss_files-2.5.so
00002b3fe4ab7000 4K r---- /lib64/libnss_files-2.5.so
00002b3fe4ab8000 4K rw--- /lib64/libnss_files-2.5.so
00002b3fe4ab9000 55112K r---- /usr/lib/locale/locale-archive
00002b3fe808b000 28K r--s- /usr/lib64/gconv/gconv-modules.cache
00002b3fe8092000 8K rw--- [ anon ]
00007fffc6208000 84K rw--- [ stack ]
ffffffffff600000 8192K ----- [ anon ]
Here we can see that there is lots of usage of the address space at low values up to the address 0x000000000b8a5000 (0x000000000b846000 + 380 Kb) but then there is a huge gap of unused space up to the next used address at 0x0000003329e00000 (/lib64/ld-2.5.so). That's a very large gap (much, much larger than 32 MB_ so this might be a good candidate to map the PLSQL segment in this process. We could chose an address of say, 0x0000000010000000 so we would set PLSQL_MEMORY_ADDRESS to 10000000 and we would be fine.
Hope that helps!