From oracle-l-bounce@freelists.org Wed May 5 09:33:30 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i45EX4X19790 for ; Wed, 5 May 2004 09:33:14 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i45EWs619741 for ; Wed, 5 May 2004 09:33:04 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 062F672D5C6; Wed, 5 May 2004 09:21:44 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03023-46; Wed, 5 May 2004 09:21:43 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3FA5872D4A0; Wed, 5 May 2004 09:21:43 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Wed, 05 May 2004 09:20:28 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2A6AA72D547 for ; Wed, 5 May 2004 09:20:21 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02441-57 for ; Wed, 5 May 2004 09:20:20 -0500 (EST) Received: from amber.monochrome.net (unknown [63.247.74.106]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 23BC872D526 for ; Wed, 5 May 2004 09:20:20 -0500 (EST) Received: from delysid by amber.monochrome.net with local (Exim 4.24) id 1BLNTO-0004Gs-D9 for oracle-l@freelists.org; Wed, 05 May 2004 09:34:10 -0500 Received: from 127.0.0.1 ([127.0.0.1]) (SquirrelMail authenticated user thump@cosmiccooler.org) by www.cosmiccooler.org with HTTP; Wed, 5 May 2004 09:34:10 -0500 (CDT) Message-ID: <43624.127.0.0.1.1083767650.squirrel@www.cosmiccooler.org> Date: Wed, 5 May 2004 09:34:10 -0500 (CDT) Subject: Re: aio on sun ufs problem From: "David Green" To: oracle-l@freelists.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Priority: 3 Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - amber.monochrome.net X-AntiAbuse: Original Domain - freelists.org X-AntiAbuse: Originator/Caller UID/GID - [32014 32014] / [47 12] X-AntiAbuse: Sender Address Domain - amber.monochrome.net X-Virus-Scanned: by amavisd-new at freelists.org Content-Transfer-Encoding: 8bit X-archive-position: 4437 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: thump@cosmiccooler.org Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org I tried to generate discussion on this list regarding this topic before, but it did'nt go anywhere. There is very little documenation and discussion out there that discusses db_writer_process vs dbwr_io_slaves in conjunction with weighing the kaio and aio pros and cons/issues as well. I have only performed these tests and eval in terms of 8i! I have done some measurements and quite a bit of reaading on this. In many ways I found and in others ways I believe that dbwr_io_slaves(with disk_aysnch_io=flase) performs better than 1 db_writer_process(with disk_asycnh_io=true). In Oracle8i, the DBWR_IO_SLAVES parameter determines the number of IO slaves for LGWR and ARCH. If DBWR_IO_SLAVES is set to a value greater than 0, then LGWR and ARCH have a default value of 4. dbwr_io_slaves can simulate asycnh io for LGWR, ARCH, DBWR and RMAN. 9i disk_asynch_io ref note: DISK_ASYNCH_IO controls whether I/O to datafiles, control files, and logfiles is asynchronous (that is, whether parallel server processes can overlap I/O requests with CPU processing during table scans). If your platform supports asynchronous I/O to disk, Oracle Corporation recommends that you leave this parameter set to its default value. However, if the asynchronous I/O implementation is not stable, you can set this parameter to false to disable asynchronous I/O. If your platform does not support asynchronous I/O to disk, this parameter has no effect. If you set DISK_ASYNCH_IO to false, then you should also set DBWR_IO_SLAVES to a value other than its default of zero in order to simulate asynchronous I/O. --- >From that, I belive that dbwr_io_slaves are more roust in terms of simulating IO for RMAN operations and arch, where as aio/kaio at the OS level only performs aio for lgwr and dbwr. There is a great deal more that can be covered or further tested in this discussion, but I must run for now...I belive reads do benefit from aio or io_slaves. In terms of db_writer_processes vs dbwr_io_slaves the general recommendation is: Should you use DB_WRITER_PROCESSES or DBWR_IO_SLAVES? ===================================================== Although both implementations of DBWR processes may be beneficial, the general rule, on which option to use, depends on the following : 1) the amount write activity; 2) the number of CPUs (the number of CPUs is also indirectly related to the number LRU latch sets); 3) the size of the buffer cache; 4) the availability of asynchronous I/O (from the OS). There is NOT a definite answer to this question but here are some considerations to have when making your choice. Please note that it is recommended to try BOTH (not simultaneously) against your system to determine which best fits the environment. -- If the buffer cache is very large (100,000 buffers and up) and the application is write intensive, then db_writer_processes may be beneficial. Note, the number of writer processes should not exceed the number of CPUs. -- If the application is not very write intensive (or even a DSS system) and async I/O is available, then consider a single DBWR writer process; If async I/O is not available then use dbwr_io_slaves. -- If the system is a uniprocessor(1 CPU) then implement may want to use dbwr_io_slaves. Implementing db_io_slaves or db_writer_processes comes with some overhead cost. Multiple writer processes and IO slaves are advanced features, meant for high IO throughput. Implement this feature only if the database environment requires such IO throughput. In some cases, it may be acceptable to disable I/O slaves and run with a single DBWR process. -----Original Message----- Subject: Re: aio on sun ufs problem That is the point. The cost and benefit of using lwp based aio on filesystem, is it worthy or not. I saw note saying the cost of thread management and context switch is big, using LWP based AIO. Does any has measured the cost? (http://www.ixora.com.au/q+a/0011/14171201.htm) Another question, does aio only means asynch write(non-blocking write), is there concept like asynch read? I did a test doing a full table scan on a table which is a raw device. The os is doing pread os call, not kaio(aioread...). If only write benefit from asynch IO, then only dbwr/lgwr will benefit from KAIO. So when dbwr and lwgr can catch up clean the dirty buffer, whether to using aio does not matters.As server process only does read on datafile, and server process used most of system resource on a big system.(server process does write only during direct read/write and creating tablespace,as far as I know). Just some thought and questions about this topic. Regards Zhu Chao. ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------