Can it be due to the fact that Enterprise Manager and Another JBoss and
the rest of the OS are taking up the rest of the memory.

The thing is I have an identical machine with a lower processor spec
(Opteron 244 vs the current opteron 280), but I have only assigned 1.8
Gig to SGA. The only problem from the old machine was the session
limits which I raised it to solve the problem. With the new machine, I
decided to experiment it a little. the only difference with the new
machine is it has a high SGA (in this case 4.2 gig when I started) and
nic bonding. Other than that, the sessions has been raise to 1200
which is high than 800 in the old machine.


On Oct 9, 2006, at 7:12 PM, Ronny Egner wrote:

> Seah Hong Yee schrieb:
>> On Oct 9, 2006, at 5:45 PM, CLEMENS.BLEILE@(protected):
>>>
>>> Hi,
>>>
>>> what di you mean with "stop accepting connection" ?
>>>
>> the client will get database connection error.
>>> Do you get an error message, does it just hang or is the connect
>>> very slow? Try with sqlplus and send the error-message.
>>>
>> No slowdown, just client having problem to connect.
>>> How much memory do you have in your system? What is SGA_MAX_SIZE,
>>> SGA_TARGET and PGA_AGGREGATE_TARGET? In addition send the output of
>>> "free".
>> This is a AMD64 system running 64 bit version of Oracle 10g
>> Value when I gotten into problem.
>> Physical memory : 8 gig
>> SGA_MAX_SIZE : 4.2 gig
>> SGA_TARGET : 2.2 gig
>> Aggregate PGA : 783 MB
>> Don't have the free output at that point but the current value is
>>         total     used     free   shared   buffers  
>> cached
>> Mem:     8125976   7581276   544700       0   546020  
>> 6226444
>> -/+ buffers/cache:   808812   7317164
>> Swap:    4200988       0   4200988
>> with the new (current) setting of
>> SGA_MAX_SIZE : 3.2 gig
>> SGA_TARGET : 3.2 gig
>> Aggregate PGA : 783 MB
>> Quesiton :
>> In "Oracle Database 10g - Linux Administration", there was a section
>> where configuring oracle for > 2.7 GB SGA.
>> It recommended the following
>> 1. Creating a ram disk by doing
>>   umount /dev/shm
>>   mount -t ramfs ramfs /dev/shm
>>   chown oracle:dba /dev/shm
>> 2. change /etc/security/limits.conf
>>   oracle soft memlock 3145728
>>   oracle hard memlock 3145728
>> 3. echo 8589934592 > /proc/sys/kernel/shmmax
>> I have often assume the above only apply to 32-bit linux systems,
>> does it apply to 64-bit version of SUSE ? since share memory
>> parameter are handle by orarun.
>
> Hi,
>
> you do *not* need to do step 1 when using 64-bit Oracle. This is only
> needed for 32-bit whith an sga > 1.7 gb.
>
>
> You have posted a top output:
>
>      total   used   free   shared   buffers   cached
> Mem:   8125976 7581276 544700     0   546020    6226444
> Swap:    4200988       0   4200988
>
> I honestly do not see your system running out of memory. You are using
> almost everything of your physical ram (either for operation system,
> database or caching) which is completely normal for linux but you do
> not
> swap (and you have up to 4 GB)!
>
> So from my point of view the problem is not in the memory allocation.
>
> My recommendation is to use up to the half of the physical memory for
> the SGA (in your case 4 GB).
>
> Perhaps the problem is the amount of user sessions and the memory
> each session takes ? When having 500 session with each 10 MB
> memory allocation you end up with 5 GB memory usage from the sessions
> themself :-)
>
> --
>
>
>
> Mit freundlichen Grüßen
>
> Ronny Egner
> Diplom-Ingenieur (BA)
>
> SIV.AG
> Konrad-Zuse-Straße 1
> 18184 Roggentin
>
> Telefon: +49 (0)3 81 / 25 24 422
> Telefax: +49 (0)3 81 / 25 24 399
>
> mailto:ronny.egner@(protected)
> http://www.siv.de
>
> **********************************************************************
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity
> to whom they are addressed. The views expressed in this
> e-mail are those of the individual author and not necessarily
> those of SIV.AG.
>
> This footnote also confirms that this email message has
> been swept by serval anti-virus tools for the presence
> of computer viruses.
> **********************************************************************
>
>
>


--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting