Community

Subscribe
Highlighted

Any way to track down what shares contributing high cifs_latency

One of filers send high cifs_latency (77 millis vs 44 misslis as normal )alert to us last night from Perfornamce Manager, since this matrix is a measurement on the filer level, as I understand. Are there any ways to look into further, and find out which share(s) causing the issue?

Thanks!

Re: Any way to track down what shares contributing high cifs_latency

could anybody please pick up the question? Thanks!

Re: Any way to track down what shares contributing high cifs_latency

Hi

   did you try using the client stats of performance advisor ?

Take a look at this TR4090 for more information on the same

TR 4090 - Performance Advisor Features and DiagnosisSmiley SurprisednCommand Unified Manager 5.0/ 5.1 Operating in 7-Mode

Regards

adai

Re: Any way to track down what shares contributing high cifs_latency

Hi Adai,

Is there similar TR for c-mode? I can find one.

Thanks

Glen

Re: Any way to track down what shares contributing high cifs_latency

Currently the PA for C-Mode doesn't have this capability.

To know more on C-Mode performance Advisor, pls take a look at this Video

Regards

adai.

Re: Any way to track down what shares contributing high cifs_latency

Hi Adai,

Thank you for the link, will watch it.

Is there any cli at DFM to list how many times the volume latency exceeded 20ms and at what date/time?

Thanks

Glen

Re: Any way to track down what shares contributing high cifs_latency

Hi Glen,

You may wish also check out Balance from NetApp.

Good luck

Henry

Re: Any way to track down what shares contributing high cifs_latency

Hi Henry,

The Balance is not free, right?

Thanks

Glen

Re: Any way to track down what shares contributing high cifs_latency

Yes Glen,

Balance is a chargeable tool.

You may wish to try the temp 90 days license from your NetApp account team.

Good luck

Henry

Re: Any way to track down what shares contributing high cifs_latency

A couple of things:

1. cifs_latency is a counter that you will find associated with each individual volume in DFM.  You can type "dfm perf data retrieve -o your_filer -C cifs:cifs_latency -d 3600" and this will show you cifs_latency value of every volume for the past hour(3600 seconds).  You can play with what comes after -o and narrow it down to just one volume/aggr/whatever, and you can specify the window with -b/-e switch.  Type dfm perf data retrieve help for more information. 

2. The volume with highest cifs_latency may not be the offender.  It probably is the one that experienced the biggest pain, but it may not have caused the issue.

3. In our environment(I'm a NetApp customer), it is very helpful to distinguish between cifs_latency and storage latency(volume:avg_latency, read_latency, write_latency).  This is because it is possible, and is often the norm in our environment, that when there is high cifs_latency and low volume-level latency, the issue exists somewhere beyond the filer.  This could be your AV scanner, or AD, or something else.   High cifs_latency is often not a filer performance issue in our environment. 

4. If the issue is something you can predictably capture, I recommend engaging NetApp support to begin data collection.  They can tell you all of this in more detail, and also look at additional data their perfstat tool will collect that DFM doesn't.