almost idle disk with queue of 200?

[Steve Post]

I have some solid state disks. they are really fast. They have no moving parts.
It is used by Sybase for a big of temp database.

According to old perf view data.
The disk is 2% busy.
It hardly has any data going to it.
Yet it has a 200 in the "queue" column.

I would expect a queue length of 0 or maybe 2. But 200? When can a queue length be 200 and a disk hardly be in use?

[Steve Post]

Maybe it would help if I added some data?

Ok.
0/6/1/0.0.0 is that RAM disk I am talking about.

0/5/1/0.1.22.0.0.1.2 is one of my EMC disks hooked up via fibre and powerpath.

It is hard for me to interpret the meaning of the data. I could think that the queue means nothing. It is a high number, but the RAM disk is so fast that it is running quickly enough that I don't really care.

Or....
The high queue and idleness of the RAM disk means that something is slowing down stuff before it gets to the disk, like perhaps the scsi card.

I am looking for some opinions here.

[Steve Post]

Looking at the definition of the metric bydsk_request_queue.
It says it is the ave number of io physical requests that were in a wait queue for this disk.

Now that can be read a few different ways.
What if all but 1 of 2000 requests went through during the measured interval. But every one of them was in a wait queue status for 0.1 pico seconds? The last request was in a wait state as it shifted to the next measured interval during that last 0.1 pico second.
Does that mean this bydsk_request_queue is at 2000? or one? or zero?

There you go. An easier, multiple choice question:
a. 2000
b. 1
c. 0
d. none of the above

[Steve Post]

ok......
Not much here. I guess that makes sense with a performance question.

Years from now, whoever tumbles upon this will give me my answer by cutting and pasting my own solution to the bottom of this thread. At least they can get some points if the answer is correct.

Oh I'll make it even easier to answer this thread. Based on the stuff I wrote above...

True or False: The queue would be a really big number, and that's fine, and I don't have to worry about it.


now I'll go read that performance cookbook pdf file ......again.

[Michael Steele_2]

HI

I'm assuming that  you are using sar but I can't tell.  Never the less, most if not all disk devices are SCSI or SCSI EMMULATION.  EMC disk arrays for example conform to SCSI Emmulation. 

I would start here and start asking the manufacturer of the RAM disk.  You probably have a new bug to report.

[cloneab]

Hey.  My old, unanswered forum entry came over.  

And I can get in. 

and it has an answer.

The disk is a solid-state device connected vis low voltage scsi.  It has no moving parts.

The data is from perfview, pulled out of measureware (or vantage point... or whatever it is called today).

I suspect the weird response has to do with the type of disk too.  But I was hoping someone has seen something like this before. 

As far as actual response on the disk?  It seems to work great.

In other news....

The forum thingy wanted me to give a handle.  So.... I guess "steve post" is called cloneab.

Seems odd.  Oh well.

[Steven E. Protter]

Shalom,

I'm guessing the solid state device is not supported by the OS. No way that is going to work.

I've seen this condition on regular disks, when there were just so many I/O processes competing for lock that none of them could get any work done.

SEP