Constant write queue

[Guest Mikey C]

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]

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