[Please don't cc me; I subscribe to the list. And that top-quoting is
very difficult to reply to.]
On Fri, Oct 18, 2002 at 03:27:29PM +0200, Yildiz, Murat wrote:
>
> thanks for your reply,
> I get this :
>
> host1#oracle:/oracle/network/admin >dbassist
>
> SIGSEGV received at bfffe2e8 in
> /oracle/jre/1.1.8/lib/linux/native_threads/libjd
> Writing stack trace to javacore15981.txt ... OK
>
> /oracle/bin/dbassist: line 103: 15981 Speicherzugriffsfehler $JRE_EXEC
> -Duser.S
> "Speicherzugriffsfehler" means Memory access error...
Ah - so it's not the database, but those new click-and-drool admin tools
suffering from memory problems.
<rant>I usually avoid those, I *like* my command line and I like being
in control... My definition of netassist is "a 25Mb application for
editing a text file" - absolute horrendeous. dbassist somewhat falls
into the same category - it's very chunky, needs loads of memory and
doesn't do anything that I'm not used to doing from sqlplus/svrmgr, and
yet lacks the flexibility...</rant>
Hm. That doesn't *necessarily* mean lack of memory, but check
/proc/meminfo anyway to be sure - as long as there is enough in
"SwapFree:" you should be ok. [No I don't know what "enough" is. Too
much for me.]
MemFree in /proc/meminfo should be taken with a (big) grain of salt, as
the kernel will try to keep as little memory (except for a couple of
meg) free as possible and use it as disk cache.
I would guess that it is a java-related error - Oracle 8 (which seems to
be what you are running) only uses JRE 1.1.8 which is close to
carbon-dateable. And God knows how it interacts with any other java
installation (kaffe, jikes, JDK 1.4 in /usr/local etc...).
I'm afraid that I can't help you much here - I avoided dbassist when I
first saw it, and when I try it now, I get:
SIGSEGV received at bfffddb4 in /usr/local/oracle/jre/1.1.8/lib/linux/native_threads/libjava.so. Processing terminated
/usr/local/oracle/816/bin/dbassist: line 103: 1222 Segmentation fault $JRE_EXEC -Duser.dir=$USER_DIR -classpath $CLASSPATH DBCreateWizard $ARGUMENTS
which looks like it likes a different version of libc (but don't take my
word for it).
> As you say we have 25 instances on this machine...
That is a bit much - far too much. How many thousand users?
> Another question is , are the values of shmmax and shmall in bytes?
Yep
>
> Murat
>
> -----Ursprüngliche Nachricht-----
> Von: Karl E. Jorgensen [mailto:karl@jorgensen.com]
> Gesendet: Freitag, 18. Oktober 2002 14:54
> An: debian-user@lists.debian.org
> Betreff: Re: Kernel parameters
>
>
> On Thu, Oct 17, 2002 at 10:47:06AM +0200, Yildiz, Murat wrote:
> >
> >
> > Hi ,
> > I have searched the maillist archive but found nothing.
> > Where can I find documentation about kernel parameters?Especially for
> those
> > under /proc/sys/fs , vm and kernel.
> > What I want to do is , lowering the filesystem cache rate, so the Oracle
> > Databases (over 20 instances) may allocate more memory.I have the feeling
> > the OS doesn't give back cached memory back when asked, because I am
> getting
> > memory errors from Oracle.
>
> What memory errors are you getting? (I'm not sure about the "feeling"; it
> seems a bit unsubstantiated.)
>
> Oracle likes to keep the SGA in memory, and uses lots of shared memory
> and a couple of semaphores to accomodate that. Check the oracle install
> guide - you should find references to modifying
>
> /proc/sys/kernel/shmmax
> /proc/sys/kernel/sem
>
> On most systems, this is not a problem, but for a highly-tuned
> production database (or a single box with lots of databases) it can get
> a little tight.
--
Karl E. Jørgensen
karl@jorgensen.com
www.karl.jorgensen.com
==== Today's fortune:
When a float occurs on the same page as the start of a supertabular
you can expect unexpected results.
-- Documentation of supertabular.sty
Attachment:
pgpl911Yg0PJv.pgp
Description: PGP signature