Re: Performance prob with raw devices
Date: 26 Jan 1994 06:09:59 GMT
Message-ID: <2i51fn$qek_at_fido.asd.sgi.com>
In article <1994Jan25.014604.13822_at_qdot.qld.gov.au>,
Michael Kubik <mak_at_qdot.qld.gov.au> wrote:
>Due to experiences gained at other sites I have
>implemented a 6.0 database using raw devices.
>The platform is a HP 9000/817 with 3 disks (1 x 2g and 2 x 1g)
>also using HPs Logical Volume Manager
>
>The problem is that the raw device tablespaces are only performing
>at 50% of a filesystem tablespaces .
Ah a question from oz.
It's a little hard to determine what exactly is causing your performance problem without knowing what sort of workload you are running. However some general comments are possible. It's not uncommon to hear this problem, most often it is caused however by one or more of the issues below. Before people start saying rew devices are a bad idea, they are not. Large databses and smaller databses that have significan I/O or can benifit from being on raw devices because of increases in I/O performance and a decrease in compute resources reuired for the filesystem. If you are a Ma and Pa shop running on a PC and are new to Oracle and/or UNIX then play it safe and stay on filesystems where things might be easier to manage. Apologies if this is kiddies stuff...
File system buffering
A file system will provide you additional read buffering through the file system buffer cache, on a raw device you don't benfit from this buffering, to be fair you should try to set DB_BLOCK_BUFFERS and the kernel NBUF (or whatever on HP) parameter so you are comparing Oracle running with the same total buffer space on each system. Oracle will make better use of buffer memory that the file system can so take memory away from the file system and give it to Oracle. Don't forget to leave something for UNIX filesystem activity if other workloads are also present on the system. SVR4 type memory pool system are particualry bad with the too high tuning defaults vendors ship for the maximum amount of memory availiable for file system blocks. This can really soak memory with filesystem blocks, giving improved I/O read performance at the expense of decrease in other performance, including possibly paging activity.
Block Sizes
Many Oracle databases are created with non-optimal blocksizes. If you have a read intensive database, especially one where you tend to perform sequential I/you may benefit from a larger blocksize. Rules of thumb are dangerous but if you know you will have a large DSS type workload then don't be frightened of creating the database with 8Kb or simmilar blocksize. People often assume the default blocksize is the best, sometimes the default blocksize for Oracle ports is set to a value for historical compatiability and has no relevence to 'best' performance under your conditions. The BSD fast filesystems has large block sizes, tuned for sequential I/O and other considerations. Most vendors with BSD fast file systems use 16 Kb block sizes. The read performance you see from reading the Oracle database through a file system cache that is mapping your (smaller) Oracle physical I/O's onto the filesystem's 16Kb block size can give a significant increase in performance for sequential read activity. You might want to investigate creating yout database with a larger block size, have a look at your workload, if you are insert/update bound or have random read patterns this may be a bad idea. As you bump the blocksize up you will need more memory for the Oracle block cache, you may need to reduce DB_BLOCK_BUFFERS and this may reduce your cache hit rate, bear this in mind.
Read-Prefetch
One of the features of the BSD fast filesystem is it is designed for good sequential performance, the large block reads and pre-reads of the filesystem can help increase sequential scan performance with Oracle. Sometimes the Oracle pre-read for a table scan is set to less than what the file system might accidently give you, when you go raw you loose this. If you are doing sequential scans try bumping up DB_FILE_MULTIBLOCK_READ_COUNT, if you are doing lots of full table scans, don't be timid with this parameter.
One other thing that a file system may provide you with is that is that you may just jag a perfrect file system rotational delay between disk blocks so you dont miss on disk rotations with sequentisl reads. Some vendors (Pyramid and others ?) provide you the ability to create logical volumes (virtual disks) that you can set raw block rotational delay on. This is pretty obtuse stuff probably only found in benchmarks and requires magic guesses at correct parameters.
>I have succesfully used raw devices before but have never used
>them inconjuction with LVM .
>
Darryl
-- Darryl Ramm Silicon Graphics Database Marketing Manager 2011 North Shoreline Blvd. darrylr_at_sgi.com Mountain View, CA, 94039-1389Received on Wed Jan 26 1994 - 07:09:59 CET