Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Filesystem read performance 1
- Thread starter verloove
- Start date
-
1
- #2
"Performance is as much of a black art as it is a science!" No two environments are the same. Different users use data in different ways at different times in the day.
Data is accessed randomly or sequencially. OLTP environments require different tuning parameters than BATCH runs. So most of us do OLTP by day and BATCH by night. A balancing act for sure.
Disk "average response time" is the "average service" + the "average wait". So if your job is the only one in the queue it is likely you are subject to how the data is layed out on the disk. If you have a lot of users hitting random locations in a database then the queue builds up, the heads bounce all around and it gets real bad if serviced by only a small number of disks.
MORE spindles matter! cached or un-cached. Under a heavy user load multiple 10K rpm drives will outperform a single large capacity 15K rpm drive. Individually the bigger badder faster new drive will out perform the slower drive of course. But put them under a heavy user load in a commercial production environment.....I tell ya, I wouldn't want to be the one going back to the well for more money to get it right using the excuse "The vendor told me this 1 or 2 big fast disks would work"
Now, if you can get the big fast disks for just a little more money (each) than the smaller ones (each), then get the new drives, but still keep the spndle count high. Multiple drive access (software striped, hardware striped RAID-0/1 yeilds higher throughput) Yes, yes, yes, then you'll have management breathing down your throat wanting you to explain why you bought soooo muuuuchhh disk space (volume). The answer is easy, you were buying spindles and the 73 GB drives were hardly more expensive than the 18's, such a deal. And then they are truly faster. Just don't trade spindles FOR volume.
Then your file systems need to be tuned with data element size settings, stripe element sizes, DARS, inode table size etc., etc.... thats another story though.
good luck
Data is accessed randomly or sequencially. OLTP environments require different tuning parameters than BATCH runs. So most of us do OLTP by day and BATCH by night. A balancing act for sure.
Disk "average response time" is the "average service" + the "average wait". So if your job is the only one in the queue it is likely you are subject to how the data is layed out on the disk. If you have a lot of users hitting random locations in a database then the queue builds up, the heads bounce all around and it gets real bad if serviced by only a small number of disks.
MORE spindles matter! cached or un-cached. Under a heavy user load multiple 10K rpm drives will outperform a single large capacity 15K rpm drive. Individually the bigger badder faster new drive will out perform the slower drive of course. But put them under a heavy user load in a commercial production environment.....I tell ya, I wouldn't want to be the one going back to the well for more money to get it right using the excuse "The vendor told me this 1 or 2 big fast disks would work"
Now, if you can get the big fast disks for just a little more money (each) than the smaller ones (each), then get the new drives, but still keep the spndle count high. Multiple drive access (software striped, hardware striped RAID-0/1 yeilds higher throughput) Yes, yes, yes, then you'll have management breathing down your throat wanting you to explain why you bought soooo muuuuchhh disk space (volume). The answer is easy, you were buying spindles and the 73 GB drives were hardly more expensive than the 18's, such a deal. And then they are truly faster. Just don't trade spindles FOR volume.
Then your file systems need to be tuned with data element size settings, stripe element sizes, DARS, inode table size etc., etc.... thats another story though.
good luck
- Status
Similar threads
