oracle performance on solaris 8 Post: 30517

Sponsored Content

Special Forums UNIX Desktop Questions & Answers oracle performance on solaris 8 Post 30517 by Perderabo on Wednesday 23rd of October 2002 11:11:34 AM

10-23-2002

Administrator Emeritus

First, it is possible to obtain an Intel box and a Sparc box such that the Intel box has several times the power of the Solaris box. Once this is done, you cannot fiddle with /etc/system and compensate. You apparently want to increase the performance of your Solaris box to 300% of its current level. It is very rare to achieve something like that by fiddling with /etc/system. Really, the only exception would be a system that is very severely mistuned to start with. You will almost certainly need to buy some hardware.

Start at the beginning. Don't change /etc/system unless you have a very specific reason. Oracle will have suggested changes to the IPC parameters. Make these exactly as Oracle wants them. If they want semmax at 64, then make it 64. The only reason to increase it further would be if you plan to run a second application that needs a lot of semephores of its own. If you set this to, say 640, you have just made your kernel larger for no particular reason. If you were short on memory before, you just exacerbated your problem. If it made any sense at all to set a parameter "up...as far as possible", there would be no point to /etc/system.

Once Oracle is running you want to be sure that you have as much memory as you need to ensure that Oracle's shared memory segments fits entirely into core together with everything else that you want to run. Thus "page-outs" should be zero. Once your page-outs are zero any more memory will just sit there and burn electricity. You do want to have some free memory, but a ton more free memory won't do any good.

At this point, your delete process should be a disk bottleneck. Since you have plenty of memory, the only other choice would be a cpu bottleneck. If we assume that your bottleneck is disk, you need to be sure that each disk is fast enough for your purposes. And that each scsi chain has enough bandwidth for the disks attached to it. And that each buss has the bandwith for the scsi chains attached to it. And so on up the i/o tree.

But even if you have enough bandwidth between the disks and the memory buss, if you have slow disks they remain slow. You can't toss a line into /etc/system and triple your disk speed.

We have never increased autoup here. If you have a very large amount memory and you have so much that you will never run short, increasing autoup may buy you a tiny amount of performance. Forget about 300% though. And you need to keep autoup as a integral multiple of tune_t_fsflushr if you really do this.

According to sunsolve:

Quote:

optional tuning parameters that improve performance slightly.

set slowscan=100

set autoup=300
set tune_t_fsflushr = 5

Perderabo

View Public Profile for Perderabo

Find all posts by Perderabo

2 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Oracle-performance tuning

Sorry, This is out of scope of this group.But I require the clarification pretty urgently. My Oracle database is parallely enabled. Still,in a particular table queries do not work "parallely" always. How is this?

2. AIX

Oracle performance optimum vs. SGA memory allocation

Dear all experts, I have a p750 Power 7 3.3GHz server with 4 processors and 48GB Memory. This is a DB server which is using Oracle 9i. I have been told that Oracle 9i can only allocate 10GB as SGA Max to get the oracle optimum performance. Anything more will result in overflow of memory and will...

LEARN ABOUT BSD

ram

RAM(4)							     Kernel Interfaces Manual							    RAM(4)

NAME

       ram - ram disk driver

SYNOPSIS

       /sys/conf/SYSTEM:
	    NRAM ram_size  # RAM disk size (512-byte blocks)

       major device number(s):
	    block: 3
       minor device encoding:
	    must be zero (0)

DESCRIPTION

       The  ram  pseudo-device provides a very fast extended memory store.  It's use is intended for file systems like /tmp and applications which
       need to access a reasonably large amount of data quickly.

       The amount of memory dedicated to the ram device is controlled by the NRAM definition in units of 512-byte blocks.  This is also  patchable
       in  the	system	binary through the variable ram_size (though a patched system would have to be rebooted before any change took effect; see
       adb(1)).  This makes it easy to test the effects of different ram disk sizes on system performance.  It's important to note that any  space
       given  to  the ram device is permanently allocated at system boot time.	Dedicating too much memory can adversely affect system performance
       by forcing the system to swap heavily as in a memory poor environment.

       The block file accesses the ram disk via the system's buffering mechanism through a buffer sharing arrangement with the buffer  cache.	It
       may be read and written without regard to physical disk records.  There is no `raw' interface since no speed advantage is gained by such an
       interface with the ram disk.

DISK SUPPORT

       The ram driver does not support pseudo-disks (partitions).  The special files  refer  to  the  entire  `drive'  as  a  single  sequentially
       addressed file.

       A  typical  use	for  the ram disk would be to mount /tmp on it.  Note that if this arrangement is recorded in /etc/fstab then /etc/rc will
       have to be modified slightly to do a mkfs(8) on the ram disk before the standard file system checks are done.

FILES

       /dev/ram 	   block file
       /dev/MAKEDEV	   script to create special files
       /dev/MAKEDEV.local  script to localize special files

SEE ALSO

       hk(4), ra(4), rl(4), rk(4), rp(4), rx(4), si(4), xp(4) dtab(5), autoconfig(8)

DIAGNOSTICS

       ram: no space.  There is not enough memory to allocate the space needed by the ram disk.  The ram disk is disabled.  Any attempts to access
       it will return an error.

       ram: not allocated.  No memory was allocated to the ram disk and an attempt was made to open it.  Either not enough memory was available at
       boot time or the kernel variable ram_size was set to zero.

BUGS

       The ram driver is only available under 2.11BSD.

3rd Berkeley Distribution					 Januray 27, 1996							    RAM(4)