Performance problem Linux vs. Solaris
MH
I have a problem with Oracle 8.1.7. I installed it on a 2 processors
Intel linux machine. The database I use is not at all optimized, means
I did not spread any datafiles across disks and I have only one tablespace.
The application working on that database produces around 2500
transactions per minute on that machine. When I install the same
database on a sunfire V280, the transaction rate goes down to 400
transactions per minute. The sunfire also has two processors, and a lot
more real memory (4 Gigabytes). When I look at the cache hit ratios,
there's no hint of contention, all ratios are above 90%. In addition,
there apear no wait events in the system.
I think that there is perhaps a problem with Solaris 2.7 and Oracle
that I don't know. Does anybody know about a certain parameter to adjust
in Oracle or Solaris, or can anybody give m an idea of what I can
exmaine to solve the problem?
Thank you for every hint
Markus
Stephan Bressler
you need to provide some more information. A good start would be to monitor
the cpu load via sar.
One topic of solaris I can think of comes with the handling of the SHM,
which may cause problems in
case of huge SGAs (>1GB) and many sessions (>200). Symptom is very high %sys
percentage of the
cpu load (>40-50%). In that case you should check whether use_ism is set to
true.
Regards
Stephan
Connor McDonald
Try
select * from v$system_event
select * from v$session_event
on each and take some deltas. This should assist informing you where
the delays are occuring
hth
connor
--
==============================
Connor McDonald
"Some days you're the pigeon, some days you're the statue..."
Mladen Gogala
Well, you are faced with a tuning problem. So, you don't have paging, no
excessive IO rates, no system contention in any shape or form. That means
that the culprit lies within the database realm. You say that there are no
significant wait events and that hit ratios are high.
Well, Cary Milsap (formerly a demigod at oracle Corp., now of the Hotsos
Inc.) has recently published a paper (see http://www.hotsos.com ) named
"Why the high hit ratio is NOT OK" in which he stresses the fact that
memory access is far from free and that while a gazillion of db block gets
satisfied from SGA will certainly perform faster then the gazillion of
physical reads, the best way to make a really significant improvement is
to reduce the amount of the db block gets in the first place.
So, what does that leave us with? Well, you have to tune your SQL.
You will first monitor CPU and see how much CPU is being used. If the CPU
usage is high, you will go to v$sqlarea and look for the most CPU intensive
SQLs. If the CPU consumption is low, then you will look for the physical
reads and rows processed. When you locate the most expensive SQL
statements (and usually, the first 5 will account for over the 90% of the
spent time) then try to tune to do their work more efficiently. That's a
classical tuning problem that helped me buy my car back then when I was a
consultant.
--
Mladen Gogala
Za Feral Spremni!
chao_ping
server. Linux with 2 p3 1.4G processors and 2G mem. Sun with 2 450
processor(8M cache) and 2G mem. I installed the same database, same
pressure on two server, and the result is that linux outperforms sun
a bit. while the linux pc server costs 30000 unit of cost, the sun
costs 200000 unit of costs. So we give up the sun machine and choose
the linux.
--
an oracle fan,
an oracle beginner
an oracle fan,
an oracle beginner
Posted via dBforums
http://dbforums.com
Eric Levinson
especially on two different platforms.
I have had queries on the same machine have hugely different resource costs,
the one with the higher cost finishes first.
I'd stongly suggest you don't just go by an explain plan and actually let
queries run to their completion with a method of timing involved.
oracle at levinsong dot com
"chao_ping" <chao...@163.com> wrote in message
news:3cf32072$1...@usenetgateway.com...