>Hello Brian
>
>Sorry for contacting you directly but I could not find any anser in the
>kernel archive concerning the Problem you described.
>
No problem.  I am cc:ing lkml in case anyone else shares this problem, 
hopefully you don't mind?
>
>I face a similiar Problem which is as follows:
>
>I wanted to migrate an Oracle Database from a Prliant Server PentiumII
>450Mhz, 450MB, Wide SCSI Raid 5, Kernel 2.2.10,
>Oracle Version 8.1.7 running under Suse 6.2 on an ext2 Filesystem
>
>The new machine is a bit faster concerning the hardware: Proliant Server
>PentiumIII 600Mhz, 512MB , Ultra2 SCSI Raid 5, Oracle 8.1.7 Suse 7.2
>Kernel 2.4.16
>
>I followed the thread and kicked out reiser, replaced it with ext2,
>installed kernel 2.2.20 and tried all those combinations to and fro with
>the flippin result that the new machine is about 2-3 times slower than the
>old one on every combination imaginable. So much for newer kernels,
>filesystems etc.
>
>Have you found a solution to the problem you described in November. If so I
>would be thankful to know
>
Our current best known 2.4.x setup is Suse 7.2 with stock 2.4.16 with 
Oracle 8.1.7, running large tablespaces (i.e. temp, rbs, large 
data/index tablespaces) on rawio over LVM over RAID10.  The performance 
seems adequate; unfortunately due to the differing workloads I do not 
have exact numbers on 2.2.x vs 2.4.16.  I haven't tried 2.2.x on this 
server yet due to boot problems.  I originally thought it a kernel 
issue, but it turns out that the "2.2.x problem" was Oracle bogosity:  
Oracle was creating core dump directories 50000+ levels deep upon 
startup, running the machine out of VM/file descriptors in the process 
(indicated by e.g. "/bin/ls: permission denied" messages even when 
logged in as root), from which 2.2.20suse could not recover (2.4.16 
handled it adequately).  So I guess I should try 2.2.x for comparison 
and report the results, although I am rather reluctant to reboot a 
production box now that we've got a stable 2.4.x.
What is your workload like?  It seems that with RAID5 you might be doing 
mostly read-only transactions?  Our workload is mostly data warehousing, 
with the (large) difference that we do bulk updates (in the millions of 
rows) on previously loaded data.  I am curious if the slowdowns we have 
experienced only affect massively write-bound Oracle instances.  Also, 
are the number of RAID arrays and the tablespace layout the same across 
the two boxes?
Regards,
Brian Strand
CTO Switch Management
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/