[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel parameters

[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?


> 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
==== 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: pgpF5dH6aTHXA.pgp
Description: PGP signature

Reply to: