could be anything, somebody running something against VNX, not even that share. Could be block connected hosts causing additional workload. Need to look at Analyzer and see what happens with array and then look at external items such such network switch load.

I just turned on the celerra monitor. I am attaching a graph here can you please look into it and let me know if this helps

Can you zoom in and see if those peaks correspond with the times users complain ?

Yes i do have and i just started performance logging info...any reasons why it would be slow for a while and comes back to normal ..as the users are using those shares all day long but only for 1 hour its being really slow....

do you have Unisphere Analyzer to look at LUNs presented to datamovers ?

Hi Bonnu06,

We are also experiencing simular slow preformance issues with CIFS Shares on the VNX5700 during the day.

Did you manage to findout the root cause of the issue? Thanks

This is a really old thread, you might want to start a new question thread.

There are a number of things that can slow down an array - in this case, at one specific time during the day. Look at virus scanning - sometimes updates can cause all scanning to get reset to a specific time of day.

Check for other jobs running on the array if you have hosts connected to the Block side.

Check KB article 12289 - this is a master article listing all the KB's for performance on Block arrays - tips on using the Analyzer program, how to's and others.

glen

Hi Glen, thanks for your reply. we have had EMC run a health check and no bottlenecks found. The VNX5700 is mainly just hosting users home directories and team CIFS Shares. All AV scanning is scheduled in the evenings and currently CAVA is disabled. The VNX is hardly pushed and CPU / Memory utilisation is low. During the day its slow and when all the users have left at the end of the day its fast again.

The reason I did not create a new post is @Bonnu06 seem to have the same problem 2 years ago. I also noticed in his other posts he hosted home directories on the VNX5700 too and then later migrated the CIFS to Isilon..... so maybe he is aware of issues with home directories on VNX5700 with CIFS???  Bonnus if you are reading this then any insight much appreciate

Regarding VNX CIFS file access problem

Migrating CIFS share from VNX to Isilon

p.s I can't seem to locate KB12289, is there a direct link? Thanks

The link is below.  These KB's are mostly for Block storage, not File. But since the back-end block storage can impact the front-end FILE part, you'd need to take a look at the LUNs and Disks for performance issues.

I'd recommend that you first stop Data Logging (if running), the Change the Archive Interval to 60 seconds (one minute polling) and Periodic Archiving enabled (to automatically collect each NAR file has it's created) then Set Log Period to non-stop and Start Data Logging. This will then collect a new NAR file every 2.6 hours on the array (the array can store 2GB per SP of NAR files, then the oldest is overwritten). This way you have the most granular polling interval (60 seconds) and you're capturing all the NARs. If you experience issues, then you can run the spcollects, gather up the NAR files that cover the time of the issue and open a case with EMC to take a look at the back-end performance during the time of the event.

You can also take this data from the NAR files (dump the NAR file to a CSV file) and import that intoa database if you wanted to keep an historical look at what you array is doing over time (or you could get one the Analyzer packages like EMC Monitoring and Reporting - I think there's a free trial for that package).

https://support.emc.com/kb/12289

glen

Hi Glen, when EMC carried out the health check they did enable logging and ran a heat map and found the disks where fine (not pushed at all). Also when the CIFS access was really slow, EMC performed a copy test within the Data Mover and that was fast. So issue is slow access to the CIFS when there are many users but the disks are fine (in the stats connection wise there were approx 10k but been told by EMC thats fine). We also ran a wireshark trace and saw requests to to the SAN but the response was slow coming back. So we have the storage blaming networks and networks blaming storage .

Thanks for the link.