[Ocfs-devel] Re: [Ocfs-users] Disappointing IMPORT Performance Using 9i RAC with OCFS on Linux

[John Smiley]

Wim,

Could you expand a bit on the problem with small I/Os
in RHAS 2.1?  Is this problem corrected in the e.27
kernel?  If not, which kernel do you recommend to
obtain the best I/O performance?

John Smiley
Sr. Database Architect
Sprint Corporation

--- Wim Coekaerts <wim.coekaerts at oracle.com> wrote:
> well, you should compare it with rhas21 isntead of
> rh8
> 
> one thing the rhas21 kernel wasn't good at was io
> grouping, it submitted
> really small io's seperately.
> 
> which kernel is this e.25 ? 
> 
> are you doing loads in parallel on 2 nodes or just a
> single node and you
> just have 2 running ?
> 
> you should download the aio patch and try with aio
> enabled.
> lemme dig up the oracle patch you can grab
> 
> Wim
> 
> 
> On Fri, Nov 21, 2003 at 05:08:58PM -0000, Kevin
> Miller wrote:
> > I am currently involved in setting up a new Oracle
> environment using 9i
> > RAC with OCFS on Linux. Part of the set-up
> involves importing the
> > application schema which comprises 5.5Gb data and
> 3.7Gb indexes. The
> > initial results are disappointing:
> > 
> > 	Linux non-RAC    Linux RAC-OCFS
> >                  60               143
> > 
> > The results are elapsed time in minutes to
> complete the full schema
> > import (using imp). They are average values from
> several runs, the
> > results from each individual run were fairly
> consistent. Neither the
> > server nor the database were restarted between
> runs.
> > 
> > The same dump file was used for each import.
> > 
> > The top five wait events for Linux RAC-OCFS
> database are:
> > 
> > Top 5 Timed Events
> > ~~~~~~~~~~~~~~~~~~                                
>                     %
> > Total
> > Event                                             
>  Waits    Time (s)
> > Ela Time
> > --------------------------------------------
> ------------ -----------
> > --------
> > io done                                        
> 1,457,317       5,550
> > 51.84
> > CPU time                                          
>              1,628
> > 15.20
> > log buffer space                                  
> 17,957       1,271
> > 11.88
> > log file sequential read                          
>  6,174         666
> > 6.22
> > log file parallel write                           
> 19,632         591
> > 5.52
> > 
> > 
> > For the Linux non-RAC database:
> > 
> > Top 5 Timed Events
> > ~~~~~~~~~~~~~~~~~~                                
>                     %
> > Total
> > Event                                             
>  Waits    Time (s)
> > Ela Time
> > --------------------------------------------
> ------------ -----------
> > --------
> > log file sequential read                          
>  6,254       1,280
> > 28.25
> > CPU time                                          
>              1,242
> > 27.40
> > log buffer space                                  
>  8,673         999
> > 22.03
> > db file scattered read                            
> 51,788         375
> > 8.28
> > free buffer waits                                 
>    744         330
> > 7.28
> > 
> > 
> > First glance would suggest that the Linux RAC-OCFS
> database is pretty
> > much IO bound, but this system has a much higher
> specification IO
> > subsystem then the Linux non-RAC system (see
> below).
> > 
> > The specification of the systems is roughly:
> > 
> > Oracle 9.2.0.4.
> > 
> > Linux non-RAC
> > RedHat 8.0 on Dual 1.8GHz Xeon (with
> hyperthreading), 1Gb RAM, 2 Ultra
> > 320 SCSI disks (not striped or mirrored)
> > 
> > Linux RAC-OCFS
> > 2*(RedHat AS2.1 on IBM x360, Quad 1.5GHz Xeon, 7Gb
> RAM), fibre connected
> > FastT Disk Array
> > 
> > 
> > Any comments?
> > 
> > (By the way, because I don't do full schema
> imports very often I'm not
> > excited about import performance in its own right,
> but I am worried that
> > the relatively poor performance is symptomatic of
> a more general issue
> > that will affect the application itself)
> > 
> > 
> > Kevin Miller
> > Oracle Database Administrator
> > Burns e-Commerce Solutions
> > 
> > 
> > 
> > 
> > 
> > 
> > 	
> 
> > _______________________________________________
> > Ocfs-users mailing list
> > Ocfs-users at oss.oracle.com
> > http://oss.oracle.com/mailman/listinfo/ocfs-users
> 
> _______________________________________________
> Ocfs-users mailing list
> Ocfs-users at oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs-users