|
|
|
|
Browse by Tags
All Tags » Performance » Storage (RSS)
-
In the next series of posts, I'll focus on SQL Server I/O, revisiting some common issues and taking a closer look at some others. In each post and as always, I'll make the case with specific data points from my tests. For the first two posts in this series, Read More...
|
-
In my previous post , I looked at how a typical OLTP workload may be affected by various controller cache configurations. And the conclusion was that giving too much cache (say all 512MB) to reads hurt the OLTP performance. The primary reason was that Read More...
|
-
In my previous post on the performance impact of controller cache configurations , I presented some empirical results showing the performance impact of configuring the controller cache to various read/write settings on large sequential I/Os. Why did I Read More...
|
-
In the next several blog posts, I’ll share with you some empirical results concerning the performance impact of configuring the read/write cache of a disk controller. In the comments on Joe Chang’s blog at this site on Storage Performance for SQL Server Read More...
|
-
Andrew Kelly in a recent post here advised visiting/revisiting the SQL Server I/O basics, and I completely agree. A firm grasp of the basics can make it easy to understand some system behaviors that otherwise may be puzzling at times. A question that Read More...
|
-
The best documentation on the I/O behavior of SQL Server checkpoints is found in SQL Server 2000 I/O Basics by Bob Dorr. In particular, you should read the following carefully: SQL Server uses the following steps to set up another page for flushing and Read More...
|
-
With the insert script and the test configurations in my previous posts , the best data load throughput was 24GB in ~7 minutes when the checkpoint (and/or transaction commit) batch size was set to 100,000 ~ 1,000,000. That was the best result when I was Read More...
|
-
In my previous posts ( 1 , 2 , 3 ), I focused on the performance behavior of setting the checkpoints and transaction commit sizes to once every 16 inserts and once every 100,000 inserts. A question remains: what is the most optimal size? In other words, Read More...
|
-
In my two previous posts on the performance impact of frequent manual checkpoints and the I/O behavior of frequent manual checkpoints , I demonstrated that frequently issuing manual checkpoints can be bad for performance and why it's bad from the storage Read More...
|
-
In my previous blog post on the performance impact of frequent manual checkpoints , I highlighted the performance peril of going overboard with manual checkpoints, and I suggested that a major contributing factor was the failure of frequent manual checkpoints Read More...
|
-
In SQL Server related storage literature, it is almost univerally recommended that disk partitions be aligned either on the 32K or the 64K boundary. On this subject, I posted some test results a while back, regarding the performance impact of disk partition Read More...
|
-
SQL Server 2005 supports placing read-only filegroups or read-only databases on NTFS compression. In other words, you can compress the database files in a read-only filegroup or a read-only database. This can be a very useful feature if saving disk storage Read More...
|
-
Recently, when I was doing some I/O performance tests on an I/O path, I found that 8K random reads (and writes) significantly and consistently outperformed 8K sequential reads (and writes) in terms of I/O throughput (megabytes per second). I was puzzled. Read More...
|
-
I had always thought that: SQL Server backup reads/writes sequentially, and SQL Server backup could fully utilize the throughput of the I/O path But I'm no longer so sure. Recently, I was doing some benchmark work on two I/O paths, and had the following Read More...
|
-
In Windows Server 2003, you can use the Disk Management console to create a striped volume over multiple dynamic disks (well, you can also create a mirrored, a RAID-5 volume, etc). If these disks (or LUNs) are presented from a SAN, most likely you can Read More...
|
|
|
|
|
|