Re: Problem with Long Checkpoints
--- "Art S. Kagel" <kagel@bloomberg.net> wrote: > > Actually the instance is mostly running well. I see you could take > advantage of more BUFFERS (there are a few FG writes on the -F > report) > and you can probably take advantage of a few more aio VPs since they > are all currently performing >1 I/O per wakeup and there should be at > least a few at <1 I/O per wakeup indicating not waiting for I/O > requests to be serviced. You can try changing LRU_MAX/MIN_DIRTY to > 1/0 from 2/1 it will help somewhat. The real problem on this server > is > that the disks are not keeping up with the demands placed on them. I > > see that from the fact that you have a HUGE RA_THRESHOLD and yet 98% > of > your read ahead is being used. That means to me that the engine has > not finished reading an RA_PAGES request when the query completes > else > there would be many orphaned RA pages with so large a threshold. > This > is to be expected from singleton and simple mirror drive disk farms. > > Also 2.1GB drives were mostly 5400RPM drives with lower data density > per cylinder which are considered slow compared to the latest 9-36GB > drives with spindles turning 10,000RPM and uch higher data density. > > I do not think that a 4GB database can gain much from striping or > RAID > but I would strongly suggest that you replace the 2.1 GB drives with > newer faster ones. That seems to be your biggest bottleneck. In > addition it is likely that those were SCSI-2 or wide SCSI-2 drives at > > 10-20MB/S interface speeds. You may look into replacing the > controllers > with Ultra-SCSI2 at 40MB/S or Ultra-SCSI3 at 80MB/S since the > 10000RPM > drives are approaching 40-60MB/S transfer to the bus themselves. > > Art S. Kagel > Thanks for the input! I will try the suggestions you have made. As I stated in my original post, I suspect(and your're confirming) that the drives are the bottleneck. We are planning to replace the disks for theses systems this year. I have read all of the posting about the dangers of RAID5, and Art's favorite 1+0 configuration. We will most likely consolidate all of the storage into one array. Physically I only need about 84 gb to hold all of my data for this project (4GB each instance * 21 instances on 8 servers when project is complete) The data ages and is purged, so I don't expect the database sizes to increase. I'm not that familiar with RAID storage offerings at this point, so theses are my concerns: 1) If I have an array configured for 84 gb, or whatever the disk form factor requires it to add up to, I am concentrating a lot of disk io on to fewer physical disks than I currently have, although they will be newer,faster disks. 2) I don't expect that I'll win the debate over RAID5 or RAID10 because the decision will most likely be based on $$$$. Performance wise, with the read/write cache maxed on the array, will I be okay? Surely it will be an improvement over my current situation. Recovery wise, I could get into trouble? One other tidbit that I have help back is that we want to consolidate storeage for several separate systems with different storage needs. Is it a bad ideas to go with one big storage array with a mixture of OLTP(84gb described above), DSS(~400), and even mainframe data sharing it? Our host storage is now on a Hitachi 7700 RAID5 array, and the host guy's love it! To my knowledge there has only been one disk failure that was hot swapped. I need arguments for RAID10 over RAID5. Thanks.....Jeff _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com