Re: The old raw devices chestnut.

Jim Smith wrote: > Note the cross-posting - but no flame wars please. > > This question was prompted by a thread on the a postgres mailing list > during which someone (Gregory Williamson) claimed > > <quote> > raw devices, at least on Solaris, are about 10 times as fast as cooked > file systems for Informix. > <quote> > > This made me think about the old arguments, and I wondered about the > current state of thinking. Some of my knowledge will be a bit out of date. > [...]] I'm still trying to figure out why ext3 filesystem under Red Hat Linux seems to be *so* much faster than ufs under Solaris... even for simple OS utilities like "find" and "cp", let alone Oracle imports and bulk inserts. Is it the journaling? Or is it the five year old hardware? ;-) Is software RAID slower than hardware RAID, or not? (do a search on this... you'll see....). I haven't worked with an Oracle raw device since version 7.3 seven years ago, and would never go back. The administrative overhead is just too much of a headache. We have Veritas Quick I/O licensed in our shop, but we never implemented it in production because it turns out the database I/O has never even been close to being the bottleneck for our particular application... and as stated, your applicatino may be different. --Mark Bole

I've found jfs to be "fast enough", considering we are moving from SQL-Server, no raw-disks on that one ( chuckles and laughs allowed :-) . The risks that raw-disks present makes me wonder if they are worth it. Restoring raw-disk databases presents its own set of problems, whereas regular files can be backed up and restored more simply and with more flexibility. After all is said and done, we already see an increase in Linux over Windows, so the expectations are different in our shop. Maybe in a situation where you need to squeeze every bit of speed out of the system are raw-disks worth it, only to have to live with the limitations of having to restore the database in the event of a crash. ( Especially with Informix, the restore horror stories alone are enought to scare me away from raw disks. And really, if you are on a SAN, aren't you wasting your time with raw disks anyway? What 'raw' disk are you really accessing on a SAN? Having used raw disks in the past vs using regular files at least from an operational viewpoint I'd go with regular files any day of the year. Perhaps good backups will offset the fear for now of anything shitting our jfs drives until we hear of something better. JFS is supposed to be improving too, to add data journaling along with the metadata in the near future. It is also 'supposedly' the lowest overhead file system, but every few months things change, and of course the high priests of Reiser will soon come down from heaven and release yet another version to mere mortals, so it looks the game changes frequently. No matter, we'll back up the database, then restore it to whatever file system is most appropriate, but no raw disks for now, they're just not portable enough. "Mark Bole" <makbo@pacbell.net> wrote in message news:3NHec.36245$az7.27185@newssvr29.news.prodigy.com... > Jim Smith wrote: > > > Note the cross-posting - but no flame wars please. > > > > This question was prompted by a thread on the a postgres mailing list > > during which someone (Gregory Williamson) claimed > > > > <quote> > > raw devices, at least on Solaris, are about 10 times as fast as cooked > > file systems for Informix. > > <quote> > > > > This made me think about the old arguments, and I wondered about the > > current state of thinking. Some of my knowledge will be a bit out of date. > > > [...]] > > I'm still trying to figure out why ext3 filesystem under Red Hat Linux > seems to be *so* much faster than ufs under Solaris... even for simple > OS utilities like "find" and "cp", let alone Oracle imports and bulk > inserts. Is it the journaling? Or is it the five year old hardware? ;-) > > Is software RAID slower than hardware RAID, or not? (do a search on > this... you'll see....). > > I haven't worked with an Oracle raw device since version 7.3 seven years > ago, and would never go back. The administrative overhead is just too > much of a headache. We have Veritas Quick I/O licensed in our shop, but > we never implemented it in production because it turns out the database > I/O has never even been close to being the bottleneck for our particular > application... and as stated, your applicatino may be different. > > --Mark Bole >

Raw disk has the potential for best performance with large tablespace and index scans in a data warehouse environment. During sequential prefetch, DB2 can make sure that the extents are contiguous on the disk if the space is DMS raw disk. It makes no difference for OLTP systems. Decision support systems that do not frequently use large tablespace scans, also will show very little benefit. To the extent that data is already in the buffer pool, it makes no difference. Software RAID does not perform well. If striping is desired, superior performance can usually be achieved by placing DB2 containers on different physical drives (or different hardware arrays) and letting DB2 stripe the data across the containers. If disks are striped by the OS or hardware using some form of RAID, you must make sure the DB2 parameter for Container Tag Size is set properly. For version 7 that means that DB2_STRIPED_CONTAINERS must be set ON or YES if RAID is used. This sets the container tag equal to the extent size (instead of using a single page). For version 8, make sure that DB2_USE_PAGE_CONTAINER_TAG is set OFF or NULL for RAID disks. This will make sure that extents after the container tag will align properly with the RAID stripes. Also be sure that the extent size is equal to or a multiple of the stripe size, and the prefetch size should be a multiple of the extent size. If data is striped by DB2 (by placing the containers on different physical drives) then the prefetch size should be n times the extent size, where n is the number of containers that are placed on different physical disks (or different physical RAID arrays). These comments relate to DB2 and are different with other DBMS'.

On 2004-04-13, Mark A scribbled: > Raw disk has the potential for best performance with large tablespace > and index scans in a data warehouse environment. During sequential > prefetch, DB2 can make sure that the extents are contiguous on the > disk if the space is DMS raw disk. It makes no difference for OLTP > systems. Decision support systems that do not frequently use large > tablespace scans, also will show very little benefit. To the extent > that data is already in the buffer pool, it makes no difference. One other point to note regarding DB2's DMS (Database Managed) table-spaces is that they don't /have/ to be on raw devices - you can use file "containers" instead (just a great big file on the file-system the entire contents of which is managed by DB2). Assuming the file system has sufficient contiguous space (or you defrag after creating one) you get the benefit of contiguous data without the complexity of raw devices. Though I haven't tried raw devices on DB2, I regularly use DMS file-based containers and have found them to be noticeably faster than the default SMS (System Managed) table-spaces (which are mostly individual files for individual database objects) with queries against massive tables. I'd be interested to know if anyone's directly compared DB2's DMS table-spaces on raw devices and file system containers. I suspect there'd be a difference - but I doubt it'd be huge. > Software RAID does not perform well. If striping is desired, superior > performance can usually be achieved by placing DB2 containers on > different physical drives (or different hardware arrays) and letting > DB2 stripe the data across the containers. Well, I do recall an interesting review of hardware and software RAID devices by Anandtech a while ago (all on Wintel boxes), in which the hardware RAID devices were outperformed by every single software RAID device they were trying. Still, benchmarks have never been a great way of measuring real-world performance, and this was only on Wintel, so YMMV. > These comments relate to DB2 and are different with other DBMS'. Same here. -- Dave Remove "_nospam" for valid e-mail address "Never underestimate the bandwidth of a station wagon full of CDs doing a ton down the highway" -- Anon.