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

[Wim Coekaerts]

in e.24 I believe, varyio wasn't really doin it's job, so io's went down
the wire in small sizes, 512 bytes, 4kb etc. this is also a problem with
some device drivers.

- highmem io would be not enabled
- varyio would not be working etc

usually happened when someone used a driver not shipped by red hat but
by another partner and it was lnked wrong. 
if you use e.27 and the correct drivers delivery BY redhat, you shoudl
be ok. if you use one created by emc or so, better be careful and make
sure the right options are turned on.

not all adapters support those features either.


On Wed, Nov 26, 2003 at 08:26:15PM -0800, John Smiley wrote:
> 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
>