Re: Hardware tips

execute the following : sar -u <interval> <number of samples> eg sar -u 2 5 : this will give you 5 metrics. Here you can see how the system is performing :

  how many % of the cpu is given to user processes
  how many % of the cpu is given to system processes
  how many % of the cpu is waiting for i/o
  how manu % of the cpu is idle

if you see a large "waiting for i/o" this means there could be a bottleneck on the i/o performance.
If so, execute sar -q x y. Look at the run-queue. If it's +5, you have a cpu performance problem. ( could be cause by a high "waiting for i/o )
If "waiting for i/o" is high, check vmstat to see if you paging.

Those are just simple unix tunig issues

Hope this helps
Gert

In article <C_5Z5.1316$pj.37861_at_news1.oke.nextra.no>,   "Sindre Solem" <sindre.solem_at_emmaedb.no> wrote:
>
> "Joe Maloney" <jrpm_at_my-deja.com> skrev i melding
> news:912m69$81a$1_at_nnrp1.deja.com...
> > How big is your SGA, particularly your DB Block Buffer pool? Sort
 Area
> > Space? Multi-Block read count? Shared Pool size? These can have a
> > bigger impact on performance than IDE. For a 768MB RAM system with
 16
> > users you should be able to handle an SGA between 256MB and 512MB
> > without difficulty (depending on transactions and table structure).
>
> I'm getting a 99.6891123 % hit on the buffer pool, 0.115 % miss on
 the
> library cache,
> 0.914 % miss on the shared pool, 0 disk sorts and the total I/O is
 very well
> balanced
> between the two disks.
>
> I have a multi-block read count of 8. Should this be much higher?
>
> The clients are connected to the server on a 100Mb network
>
> >
> > Also, remember that the SGA should not be swapped out. It is
 supposed
> > to be resident, so be sure to check the OS virtual memory, etc.
> >
> > Second consideration, two drives is 3 too few, ideally, unless you
 are
> > dealing with something like EMC or a multiple channel controller.
 BUt,
> > for only 15 users, the transactions should be too quick for that to
 be
> > a major factor.
> >
> > Third and most important, consider the table structure and
 transaction
> > sql. Are you doing a lot of table scans? The usual ground rule is
> > that performance is 70% application logic (including things like
 what
> > are the indexes, etc.).
>
> The same application/db is running smoothly on new NT servers (with 2
 SCSI
> disks).
> This makes me suspect hardware/OS tuning issues.
>
> > In article <912kjm$6o4$1_at_nnrp1.deja.com>,
> > Dennis <dwehlman_at_my-deja.com> wrote:
> > > I run Oracle 7 and 8 on a Sun Sparc 20 with 192 MB RAM and
 external
> > > disk pack. There was more than 15 users working with the instance
 at
> > > the same time with an OLTP application. And there was no problems.
> > > Is disk i/o slow down your system?
> > > Check swapping of your system.
> > > Check Oracle server parameters (buffers ...) in initSID.ora.
 Reduce
> > > memory allocation of Oracle if needed.
> > > I think it's not only your IDE disk slow down your system.
> > > Dennis
> > >
> > > In article <y12Z5.1073$pj.33475_at_news1.oke.nextra.no>,
> > > "Sindre Solem" <sindre.solem_at_emmaedb.no> wrote:
> > > > We're running Oracle 8.1.6 on a Sun Ultra 10, with 768 MB
 memory and
 to
> > > > disks. What we're finding is that the performance is
 unacceptably
 low
 for an
> > > > OLTP type application for up to 15 simultaneous users. Could
 this be
 because
> > > > it's and IDE based I/O system? Does anyone else have any
 experiences
 with
> > > > this server? Is it too much load for this server to handle?
> > > >
> > > >
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> > >
> >
> > --
> > Joseph R.P. Maloney, CCP,CSP,CDP
> > MPiR, Inc.
> > 502-451-7404
> > some witty phrase goes here, I think.
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Mon Dec 11 2000 - 10:31:26 CST