<$BlogRSDUrl$>

Thursday, January 06, 2005

Anyone who follows Oracle at all cannot help but have noticed the attention Oracle Corp has been paying to Linux in 2004. I can't see this changing as I believe that they rather suspect that a good chunk of the proprietory Unix market will move to cheap intel boxes running linux over the next 5 years or so. I'll admit that I believe this, largely because I consider this to be correct.

Anyway I have just recently taken the plunge and installed Fedore Core 3 on a couple of machines. One immediate thing that I wanted to do was to get and publish some figures on comparative performance of Oracle on Windows and Linux. Threads like this one where figures such as '4x faster on Linux than Windows' are quoted without saying what the tests were annoy me somewhat. In fact the only paper that I am aware of on the subject is Roby Sherman's - and that is only available at archive.org now.

I'll be writing up a paper shortly on a proper investigation, but thought that the following simple test on identical hardware (the same pc) would make interesting reading.

The hardware is an intel based p4 laptop with 512mb ram. For windows the database is 10.1.0.2, for linux the database is 10.1.0.3. (i.e the databases available for download from otn.) In both cases the database is the supplied 'general purpose' database. In other words this doesn't at this stage attempt to apply any common sense at all to the installation, merely install off the shelf software.

The script run in each case generates a simple table and then traces the execution of 6 inserts into the table using the DBMS_MONITOR PL/SQL package.


create table t1
as select * from all_objects
where rownum < 20001;

exec dbms_monitor.session_trace_enable();

insert into t1 select * from t1;
insert into t1 select * from t1;
insert into t1 select * from t1;
insert into t1 select * from t1;
insert into t1 select * from t1;
insert into t1 select * from t1;

exec dbms_monitor.session_trace_disable();


On the windows installation this resulted in the following resource profile.

Event Times Max. Wait Elapsed Average
db file scattered read 1095 0.52 62.39 0.06
CPU 42.44
Unaccounted For 37.90
control file sequential read 1173 0.31 36.01 0.03
log buffer space 634 0.4 29.83 0.05
log file switch completion 104 1.02 25.20 0.24
rdbms ipc reply 109 0.42 22.05 0.20
db file sequential read 309 0.14 6.12 0.02
log file sync 99 1.02 3.83 0.04
db file parallel read 11 0.47 2.36 0.21
control file parallel write 138 0.43 1.33 0.01
enq: CF - contention 8 0.37 1.21 0.15
log file switch
(checkpoint incomplete) 2 0.26 0.38 0.19
db file single write 69 0.1 0.21 0.00
control file single write 69 0.09 0.20 0.00
SQL*Net message from client 7 0 0.01 0.00
SQL*Net message to client 7 0 0.00 0.00
ksfd: async disk IO 131 0 0.00 0.00
latch: redo writing 1 0 0.00 0.00
latch: cache buffers lru chain 1 0 0.00 0.00

Response Time 271.47



On Linux the self same test ran in 70% of the time with the following resource profile.


Event Times Max Elapsed Average
log buffer space 2284 0.22 88.20 0.04
log file switch
(checkpoint incomplete) 92 1 66.80 0.73
CPU 26.40
log file switch completion 113 1 6.34 0.06
db file sequential read 56 0.09 0.78 0.01
db file scattered read 580 0.1 0.61 0.00
Unaccounted For 0.08
db file parallel read 1 0.04 0.04 0.04
SQL*Net message to client 7 0 0.00 0.00
SQL*Net message from client 7 0 0.00 0.00
latch: cache buffers lru chain 1 0 0.00 0.00

Response Time 189.25


One of the interesting things is to note the large value of unaccounted for time on the windows box - this is almost certainly down to process pre-emption caused by unnecessary services running. I expect to put results of tuning this exercise up later next week.


0 Comments
0 Comments: Post a Comment