Hi all.
As we expected, the problem was not with the OS, but with the
application. It fell into an endless recursion and sucked up CPU and all
the memory it could get. Process after a process, we would run out of
swap and the machine would be unusable.
Thanks to all who responded.
<alan_at_nabeth.cxo.dec.com> Has cleared some issues with memory allocation
options.
The amount of stack space a program will use can't be
usefully predicted when the program is compiled. To
see this take a recursive function that uses some stack
space. Arrange for it to be called a number of times
determined by the user at run-time...
Some types of data get a.out space allocated for them
(initialized data), but others don't. They just get
zero filled pages upto the data size of the process
whenever the memory is referenced.
Unless an application is aware of the setrusage(2)
system call, the limits on memory use are inherited
from the shell and the values of per-proc-stack-size,
per-proc-data-size and per-proc-address-space. You
may want to find out from Oracle if the lack of memory
is stack or data and then adjust the appropriate per-proc
limit to match the max-per-proc limit.
Also check to see how much page/swap space is reserved
when this is happening. You might be running out.
"Karen R. McArthur" <kmcarthu_at_bates.edu> shared his IPC subsystem
settings with us.
We have Oracle 7.3.4 running on Alpha 2100, 1 CPU, 1GB RAM, 4GB swap,
Tru64
4.0D
(Recommended to have swap ~4x memory)
We actually have 4 instances of Oracle running on this server. Our
largest
Oracle Instance has a very large SGA - thus the large "shmmax".
maxusers 128
maxuprc 96
# Oracle-specific semaphores
semmni 200 # number of semaphore identifiers
semmns 10000 # number of semaphores in the system
semmsl 50 # max semaphores per user ID
semopm 30 # max operations per "semop" call
semume 30 # undo entries per process
shmmax 268435456 # max size of a single shared memory segment -
must
be larger than largest SGA
shmseg 64 # shared memory segements per process
semvmx 32767 # max value of semaphore
semaem 16384 # amount used to adjust max val of semaphore on
exit
msgmax 65536 # max message size
msgmnb 65536 # max length of a message queue
"David J. DeWolfe" <sxdjd_at_java.sois.alaska.edu> lent some helpful
advice.
"Raul Sossa S." <RSossa_at_datadec.co.cr> gave some advice from his
expirience:
1. Install Oracle 7.3.4.5.0 patch kit for Compaq Tru64UNIX.
2. Increase your SGA size to 60% (specially sharedpoolsize and
dbblockbuffers).
(if you don't have character aplications running agains Oracle DB).
3. Increase your Phisical Memory (512MB seems to be not good for a
serious
Compaq AlphaServer 4100 and Oracle) (I know why I'm telling you this,
I've been working with this alphas and oracle during last 10 years).
4. Tune your Memory variables at the initSID.ora
5. Put your shm-max variable at /etc/sysconfigtab equal to your 70% of
Total
RAM Memory Size.
6. Install Patch kit number 6 of Compaq Tru64UNIX 4.0D (last one).
Nix.
Received on Mon Nov 13 2000 - 06:51:26 NZDT