This post is more than 5 years old

2 Intern

 • 

360 Posts

4547

March 29th, 2008 11:00

About "Average Busy Queue Length"

Dear All,

I would like to check the performance of specific RAID Group is good or not.
Can I check the value of "Average Busy Queue Length" to verify?

what is the good value if I can use it to check?

Thanks for any reply.

Dennis

6 Operator

 • 

4.5K Posts

April 4th, 2008 09:00

it has to do with the amount of time that the SPS batteries can keep the array running during a power fail and how long it takes to dump the write cache to disk.

regards,

glen

6 Operator

 • 

5.7K Posts

April 7th, 2008 00:00

Isn't it possiblle to have these batteries somewhat bigger and have, let's say, 6GB of write cache ? Nowadays with these NiMH batteries you see in every household, I would think this isn't a big issue.....

2 Intern

 • 

360 Posts

April 12th, 2008 02:00

The value of service time are often higher than 300 ms, but I never get the complain form my client.

Is it possible that value are not accurate?

Dirty Cache % are always under 80 and no I/O size is greater than 1023K.
So furthur I/O will fit into cache and then state to physical disk.
is above concept right?

6 Operator

 • 

5.7K Posts

April 14th, 2008 02:00

Dirty Cache can be almost 100%. Of course you have a forced flushing going on at that point, but still it's 100% (I've seen a constant 97% a week or 2 ago when I had a problem with that Clariion - still that is something to consider as well).

6 Operator

 • 

4.5K Posts

April 16th, 2008 14:00

Are you looking at the real-time analyzer or using the NAR files? If using NAR files, what is the archive interval set to - 600 seconds or 60 seconds.

If using NAR files to track down your problem, use 60 seconds to get greater detail.

Look at queue length (as measured value) and Total Throughput (another measured value). Look for LUNs with high queue length (over 10), Utilization over 70% and response time over 20ms at the same time point. You need all three of these values to exceed the Best Practices guidelines.

Dirty Pages going to 80% and then dropping back to 60% indicates that the watermarks are operating correctly - keeping your write cache efficient. Over 80% and you start to force flush. If you hit 99%, the write cache shut down until the writes are de-staged to disk. If the disks can't keep up with the writes, the queue increases and write cache dirty pages can stay at 99%. Too many writes or IO's to the LUN can bog down the disks.

glen

2 Intern

 • 

360 Posts

April 17th, 2008 05:00

Dear Kelleg,

Thanks for your response.

I will check the archive interval set, I used the default value about it.
The Cache usage are good for normal operating, but I may get higer respone time.

The root cause may be followings:
1. CX3 mirror to CX700 and CX700 is the bottleneck.
2. I can see any details of mirrored LUN via Navisphere Analyzer. Is it normal?
3. CX700 used the temp anlyzer license for troubleshooting.

Best Regards,
Dennis

2 Intern

 • 

360 Posts

April 17th, 2008 05:00

Sorry!

I forgot a word.

I can not see any details of mirrored LUN via Navisphere Analyzer. Is it normal?

2 Intern

 • 

360 Posts

April 17th, 2008 07:00

Dear Glen,

Thanks for your quickly response.

I can not see any performance data of mirrored LUN on remote storage (CX700).
Is it possible cause that we use Rebootless Analyzer enabler for R14, R16, R17, R19 and R22 on remote storage?

Best Regards,
Dennsi Dai

1 Rookie

 • 

103 Posts

February 16th, 2010 09:00

RRR wrote:

I'm thinking out loud here.... why isn't it possible to dedicate let's say 6GB to write cache and 1GB to read cache ? What is the use of having 8GB if you can only have 3GB write cache ?

I know this is an old thread, but I wanted to respond to your question just in case you didn't get the answer. I'm sure you already know though.

My understanding was that because the older Clariion was running on a Windows 32bit OS that it cannot have more than 4GB. And the new Clariions are supposed to be running on 64bit OS now.

I could be wrong though.

No Events found!

Top