Re: MORE RAM - BIG CONTROLLER CACHE / DB ON RAW - DB ON FS
Do not use UFS it takes a long time to FSCK after a crash. Veritas is the filesystem to use if you are going to use filesystems. I made some trials but with Oracle databases and in a Unisys box with a Milex controller (RAID 5). The result was that is performed much better with the filesystem than with the raw partition. Also made a lot of difference to set the write policy in Write Through (don't wait). By the way although in HP you have a lot of help from the Logical volume manager in boxes like the Unisys, using filesystems gives much more flexibility to the management of disk space. >From owner-informix-list@iiug.org Mon Jan 18 09:10:16 1999 >Received: (from majordom@localhost) by iiug.iiug.org (8.7.5/8.7.3) id LAA10531; Mon, 18 Jan 1999 11:06:17 -0600 (CST) >Received: from iserver.raychem.com (iserver.raychem.com [206.175.153.2]) by iiug.iiug.org (8.7.5/8.7.3) with ESMTP id LAA10516 for <informix-list@iiug.org>; Mon, 18 Jan 1999 11:05:48 -0600 (CST) >From: MOPSOMER@raychem.com >Received: from wh1.mnlo.raychem.com (wh1.mnlo.raychem.com [159.57.1.39]) > by iserver.raychem.com (8.8.6/8.8.6) with ESMTP id JAA07256 > for <informix-list@iiug.org>; Mon, 18 Jan 1999 09:01:02 -0800 (PST) >Received: from mailxchg.raychem.com by wh1.mnlo.raychem.com (8.8.8+Sun/SMI-SVR4) > id IAA16255; Mon, 18 Jan 1999 08:59:52 -0800 (PST) >Received: from ccMail by mailxchg.raychem.com > (IMA Internet Exchange 2.12 Enterprise) id 0033D017; Mon, 18 Jan 1999 09:04:30 -0800 >Mime-Version: 1.0 >Date: Mon, 18 Jan 1999 17:39:52 -0800 >Message-ID: <0033D017.1246@raychem.com> >Subject: MORE RAM - BIG CONTROLLER CACHE / DB ON RAW - DB ON FS >To: informix-list@iiug.org >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Content-Description: cc:Mail note part >Sender: owner-informix-list@iiug.org >Precedence: bulk > > I recently had a discussion with a consultant. The following is a > replay of this discussion. I just wanted to see your opinions on it. > > I : Why do you only sell storage arrays with no cache or a small one ? > X : Disk subsystems with GBs of NVRAM come from the mainframe world, > where memory prices are high and memory capacities quite low. > In the open systems world, RAM is not expensive, so it is better > to spend your money on extra GBs of RAM as this is much faster > and the OS, DB and application can use that RAM more intelligent > than that the disk subsystem controller can do with its big cache. > I : Okay, but our BUFFERS are already set at the maximum (768.000) > and shared memory in Solaris 2.5.1 is limited to 3.75 GB anyway. > X : The biggest benefit from controller caches comes from enabling > fast-writes and colescing writes. The effect of the controller > cache on reads is very limited, as your database is over 300 GB. > For the fast-writes, you do not need a cache which is several GB. > I : Okay, but what about the RAM that I can't use for the BUFFERS ? > In Informix 7.30, the maximum number of BUFFERS is still the same. > And even if I could set BUFFERS much higher, my checkpoints would > probably become much too long for an OLTP environment. I already > have checkpoints which take between 10 and 15 seconds nowadays. > X : You could also put your db in filesystems instead of using raw. > I : This is new to me. I thought filesystems were much slower ! > X : The difference is not that big anymore. With the direct I/O > improvements in Solaris 2.6 and the usage of Veritas VxFS instead > of UFS, you will get performance comparable to raw disk, but the > investment in additional RAM can be used as filesystem cache, so > you can indirectly increase your Informix BUFFERS, avoiding a lot > of expensive disk I/O or I/Os satisfied by the controller cache. > I/Os satisfied by RAM are much faster than the controller cache. > I : [End of discussion; surprised by the statements on raw versus fs] > > Any ideas or comments on this ? > Did somebody already convert their Informix databases from raw disk to > UFS or VxFS (for performance reasons) ? Is it indeed a better idea to > invest in RAM than going for a big controller cache (4-16 GB) ? Where > does that 768,000 limit for the ONCONFIG parameter BUFFERS come from ? > Would it indeed make no sense (no performance improvements) to have 4 > GB of BUFFERS instead of the 1.5 GB which is the maximum in Informix ? > > Mario Opsomer > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com