SUMMARY: Performance problem

From: Oliver Butanowitz <Oliver.Butanowitz_at_alis.de>
Date: Mon Nov 04 2002 - 02:55:41 EST
Hi,

thanks for the fast and good answers.
About 50 % told me that my tests are not the right
way to test oracle performance. And they are right :)
But i didn't want to test oracle performance - as
we don't have any problems there. 
And with the other 50 % of answers i understand why it is
like described.

Direct I/O bypasses the filesystem buffer cache, so "normal"
operations like cp / mv etc. are much slower.
As oracle use it's own buffers this boost performance, mainly by
avoiding the "double copy" of data into the filesystem buffer cache
and from there into the shared memory segment.

I didn't expect the performance loss for normal filesystem operations
so clear.

Thank you all
for your help

Oliver


<--- cut here ---->

Hi !

We are implementing a SunCluster 3.0 in our environment.
During this project we got a recommendation from sun to
use the "forcedirectio" option for oracle filesystems.
Last weekend i reorganized our oracle filesystems. 
In this case i moved some large datafiles between filesystems.
This operations were really slow (compared to my expierence from
older reorganziations), so i did a test with a new filesystem without 
the forcedirectio option:

sun1:root> mount -F ufs -o global,logging /oracle/AHP/sapdata98
sun1:root> mount -F ufs -o global,logging /oracle/AHP/sapdata99

sun1:root> ls -al /oracle/AHP/sapdata98/dir
total 2049072
drwxr-xr-x   2 root     other        512 Oct 31 09:55 .
drwxr-xr-x   5 root     root         512 Oct 31 09:55 ..
d-rw-r-----   1 oraahp   dba      1048584192 Oct 30 14:12 file.dump

sun1:root> ls -al /oracle/AHP/sapdata99
total 36
drwxr-xr-x   4 root     root         512 Oct 31 10:06 .
drwxr-xr-x  26 oraahp   dba         2048 Oct 30 12:03 ..
drwx------   2 root     root        8192 Oct 30 14:23 lost+found

sun1:root> time cp -rp /oracle/AHP/sapdata98/dir /oracle/AHP/sapdata99/dir

real    5m41.09s
user    0m0.04s
sys     0m48.41s

# yeah, now it's not fast, but both filesystems are on the same disk :)

sun1:root> rm -r /oracle/AHP/sapdata99/dir
sun1:root> ls -ali /oracle/AHP/sapdata99/
total 36
         2 drwxr-xr-x   4 root     root         512 Oct 31 10:17 .
         2 drwxr-xr-x  26 oraahp   dba         2048 Oct 30 12:03 ..
         3 drwx------   2 root     root        8192 Oct 30 14:23 lost+found

sun1:root> umount /oracle/AHP/sapdata98
sun1:root> umount /oracle/AHP/sapdata99
sun1:root> mount -F ufs -o global,logging,forcedirectio /oracle/AHP/sapdata99
sun1:root> mount -F ufs -o global,logging,forcedirectio /oracle/AHP/sapdata98

sun1:root> time cp -rp /oracle/AHP/sapdata98/dir /oracle/AHP/sapdata99/dir

real    29m34.66s
user    0m0.19s
sys     0m46.46s

sun1:root>

This is what happens. The cp with forcedirectio needs about 6 times more time.
We are using Solaris 8, patches are up to date. It's a E4500 with A5x00 
arrays. The ufs filesystem were created with newfs -f 8192 -b 8192 -i 20000 

Question:
What is your experience with forcedirectio ? 
What is your recommendation regarding this options with oracle DB ?
Any solutions ??

Thank you in advance for your informations,
i'll try to summarize them later.

cu

Oliver
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Mon Nov 4 02:57:55 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:57 EST