none
How to debug CIFS performance problem? RRS feed

  • Question

  • Hi,

    We are facing an I/O bottleneck on our production servers. Following is brief description of the problem

    We have an I/O intensive ASP.NET application which does I/O using CIFS on NAS. We are observing difference in throughput on the NAS in following scenarios

    1. On our staging servers from ASP.NET app which writes onto \\X\Y\Z UNC location, we get 5-6MB/sec.
    2. On production servers from ASP.NET app which writes onto \\X\Y\W UNC location, we get 1-2MB/sec.
    3. When we run an application (which simulates our ASP.NET app and is a windows application) from production servers we get a throughput  of 10-12MB/sec (writing to same location as production).

    NOTE: Same application is installed on staging and production servers. And folder 'W' (used in production) has much more folder and files as compared to folder 'Z'(used in staging).

    I don't know why there is so much difference in throughput and would like to debug it to find out why. This driving me nutss!!

    I have tried taking TCP dumps (checked the SMB blocks) but couldn't find any problem there. Time taken by I/O operations when calculated using SMB request-response as compared to time taken by I/O operations calculated from with in the ASP.NET application varies considerably(performs much slower). This seems to suggest there is a bottleneck in the application  but i dont know for sure.

    Is there any other ways which can help me debug the problem. Can some show me the way?

    -Sumit
    Tuesday, December 9, 2008 3:58 PM

Answers

  • Debugger,

    As stated previously, the interoperability forums are for interoperating with our windows protocol documents.  It appears you are getting some assistance in our windows server forums here which is a more appropriate place to assist you with your issue.  I would also like to re-iterate that you also consider opening a case with Microsoft product Support.

    Richard Guthrie
    Escalation Engineer
    Wednesday, December 10, 2008 3:13 PM