Guest Mikey C Posted November 23, 2007 Posted November 23, 2007 Windows Server 2003 SP2, SQL Server 2005 SP1. 2GB RAM. 2 x Intel Xeon 1.86GhZ. 2x RAID 1 arrays, 1 x RAID 5 array. Hello people. We have a very perplexing problem involving a constant write queue on two of three raid logical volumes. We have Win2003 and SQL Server 2005 is installed on drive C (RAID 1). The database files themselves are installed on drive P (RAID 5). The log files are on drive L (RAID 1). SQL is the only application installed on this server. This is a production server under moderate load. Drives C and L have a constant write queue, as indicated in performance monitor. The queue on L is slightly higher than the queue on C. There are no read queues on these drives. Drive P has a slight read queue, but no write queue. If we stop the SQL services then the queue goes away. CPU utilisation is normally < 2%. As we expect there to be a fair number of writes on drive L (the log drive), we are trying to diagnose first and foremost what is causing the write queue on drive C. We have pointed FileMon at this drive to see what files are being written, but there is virtually no activity (we're talking about a few kilobytes written per second tops). The swap partition is on this drive, so we though a lack of RAM could be leading to paging, but the page faults counter barely goes above the base line, so we don't believe it can be this. The machine has about 70 MB free physical RAM, but this is expected as SQL should take as much as possible for caching purposes, right? Here is an image from performance monitor showing the drive C write queue and page faults under a standard load: http://unitedwholesale.com.au/tmp/perfmon.gif Could any gurus reading this advise us as to what their next move would be to diagnose what is causing this write queue? Or is it indeed a problem at all? Thanks in advance for any advise or suggestions, Mike
Guest Mikey C Posted November 27, 2007 Posted November 27, 2007 Re: Constant write queue On Nov 23, 5:48 pm, Mikey C <mikeachamberl...@gmail.com> wrote: > Windows Server 2003 SP2, SQL Server 2005 SP1. 2GB RAM. 2 x Intel Xeon > 1.86GhZ. 2x RAID 1 arrays, 1 x RAID 5 array. > > Hello people. > > We have a very perplexing problem involving a constant write queue on > two of three raid logical volumes. > > We have Win2003 and SQL Server 2005 is installed on drive C (RAID 1). > The database files themselves are installed on drive P (RAID 5). The > log files are on drive L (RAID 1). SQL is the only application > installed on this server. This is a production server under moderate > load. > > Drives C and L have a constant write queue, as indicated in > performance monitor. The queue on L is slightly higher than the queue > on C. There are no read queues on these drives. Drive P has a slight > read queue, but no write queue. If we stop the SQL services then the > queue goes away. CPU utilisation is normally < 2%. > > As we expect there to be a fair number of writes on drive L (the log > drive), we are trying to diagnose first and foremost what is causing > the write queue on drive C. We have pointed FileMon at this drive to > see what files are being written, but there is virtually no activity > (we're talking about a few kilobytes written per second tops). The > swap partition is on this drive, so we though a lack of RAM could be > leading to paging, but the page faults counter barely goes above the > base line, so we don't believe it can be this. The machine has about > 70 MB free physical RAM, but this is expected as SQL should take as > much as possible for caching purposes, right? > > Here is an image from performance monitor showing the drive C write > queue and page faults under a standard load: > > http://unitedwholesale.com.au/tmp/perfmon.gif > > Could any gurus reading this advise us as to what their next move > would be to diagnose what is causing this write queue? Or is it > indeed a problem at all? > > Thanks in advance for any advise or suggestions, > > Mike Though I'd let anyone interested know that it was a RAID configuration issue. Changing all volumes from write-through to write-back caching solved the problem. Mike
Recommended Posts